fix(frontend): recover rectification and consultation retries
This commit is contained in:
Jesse_Chen
@@ -3436,3 +3436,32 @@
|
||||
- 防复发：所有可发布 Web 镜像必须在 `next build` 阶段注入与镜像/发布清单相同的完整 Git SHA；仅设置容器运行时变量无效。发布验收必须覆盖已登录页面和静态资源 deployment marker，不能只看 `/api/health`。
|
||||
- 相关记录：`deploy/README.md`、`deploy/railway-web.Dockerfile`、staging/production exact-SHA release workflows
|
||||
- 修复版本：待提交（精确 SHA 以重新发布后的远端分支与 production health 为准）
|
||||
|
||||
## BUG-205 | 普通咨询参数重试复用已拒绝计算缓存并误报运行合同未完成
|
||||
|
||||
- 状态：resolved（本地修复，未提交、未发布）
|
||||
- 首次发现：2026-08-16
|
||||
- 最近更新：2026-08-16
|
||||
- 影响面：普通咨询 Mastra Agent 在同一 Agent 执行尝试内对 `run-jyotish-consultation` 的参数纠正、服务端运行合同补跑与计算 Promise 去重。
|
||||
- 用户现象：普通咨询运行较长时间后返回“Agent 未完成必要的方法与计算步骤，本次不会扣点”，实际主咨询 workflow 一次也没有执行。
|
||||
- 触发条件：模型首次同时传入 `domains` 与兼容字段 `theme`，触发 `invalid_consultation_domain_plan`；随后模型或服务端合同补跑改用合法 `theme: timing` 再次调用同一上下文绑定工具。
|
||||
- 根因：`createConsultationTools()` 在 `canonicalDomainPlan(input, ctx)` 参数校验前就创建并缓存 `calculation` Promise。首次非法调用产生的 rejected Promise 被永久保留；后续合法调用命中缓存后直接复用旧拒绝，导致 workflow 调用数保持为零，最终由既有合同门禁判定 `runtime_contract_incomplete`。
|
||||
- 修复：在读取或写入计算缓存前同步完成域计划校验，非法参数不启动、不计数也不污染缓存；实际计算 Promise 拒绝时仅清除仍指向该 Promise 的缓存，使后续调用可以重新执行。成功 Promise 继续保留，合法并发调用仍共享同一次服务器计算。未移除运行合同门禁，未伪造 workflow receipt 或成功状态。
|
||||
- 验证：新增 invalid `domains + theme` → valid `theme: timing` 回归，确认首次 workflow 调用数和工具调用计数均为零、第二次合法调用执行一次并完成合同；新增 workflow Promise 首次拒绝后后续调用不复用旧拒绝的回归；既有合法并发调用只计算一次测试继续通过。`frontend/tests/consultation-agentic-runtime.test.ts` 共 15/15 通过。
|
||||
- 防复发：所有可复用的请求级 Promise 必须先完成同步输入合同校验再缓存；rejected Promise 不得长期占用幂等缓存。并发去重测试必须同时覆盖合法并发、非法后合法重试和真实异步拒绝后的缓存释放。
|
||||
- 相关记录：BUG-186、BUG-189
|
||||
- 修复版本：本地未提交候选
|
||||
|
||||
## BUG-206 | 新用户完成初始化后首页生时校正打开失败被静默吞掉
|
||||
|
||||
- 状态：resolved（本地修复，未提交、未发布）
|
||||
- 首次发现：2026-08-16
|
||||
- 最近更新：2026-08-16
|
||||
- 影响面：新用户完成出生资料初始化后，从首页“生时校正”卡片打开 V9 Agentic Rectification Case 的入口错误处理。
|
||||
- 用户现象：用户完成初始化资料后点击首页“生时校正”，页面没有切换，也没有显示任何错误，看起来像按钮没有反应。
|
||||
- 根因：`POST /api/rectification/cases/open` 返回 `profile_incomplete` 时，客户端仅在本地 `missingProfileStep(profile)` 非空时处理；新用户本地资料已被判断完整时该分支不更新任何 UI 状态便直接返回。网络异常同样只写入未渲染的 composer notice，导致 Case 未打开时没有可见反馈。
|
||||
- 修复：服务端 `profile_incomplete` 统一进入既有资料重新确认流程；`invalid_open_request` 与网络异常写入可见的 rectification error；首页入口附近增加 `role="alert"` 错误提示。成功响应后的 Case/Session 合并与校正界面切换逻辑保持不变。
|
||||
- 验证：新增修复前失败的首页 open 错误回归，锁定 profile incomplete、invalid request、网络异常和可见 alert；修复后聚焦入口测试 69/69 通过，`git diff --check` 通过。
|
||||
- 防复发：首页业务入口不得把 API 失败只写入未渲染状态；本地资料完整与服务端资料不一致时必须提供可见错误和恢复动作，不能静默返回。
|
||||
- 相关记录：BUG-177、BUG-198、BUG-199
|
||||
- 修复版本：本地未提交候选
|
||||
|
||||
Reference in New Issue
Block a user