docs: BUG-1047 deployed (8a409434)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017eEAG8HD3mm8gsKXgk8uU8
This commit is contained in:
Jesse_Chen
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
8a40943455
commit
3ce11ee04d
+1
-1
@@ -14023,7 +14023,7 @@
|
||||
|
||||
## BUG-1047 | 生时校正打字回答后要等很久才有动静：开流前无反馈、分类无超时、线上看不出时间花在哪
|
||||
|
||||
- 状态：investigating（D2/D3/D4 与 D5 的两项前端优化已实现并有回归测试，本地 `next start` + 无头 Chrome 虚构数据验证；未部署，真实模型下的单轮耗时需部署后用新埋点复核，不写 resolved）
|
||||
- 状态：resolved（Claude 2026-09-26 用 Node 22 独立复验通过；门禁 run 2928、迁移 2929 成功并已部署，`/api/health` `gitCommit` = `8a409434`；真实各段耗时待用新埋点日志复核，真机清单由产品走）
|
||||
- 首次发现 / 最近更新：2026-09-26 / 2026-09-26
|
||||
- 影响面：`POST /api/rectification/agent`（`route.ts` 的 message 分支）、`turn-intent-classifier.ts` `classifyTurnIntentWithRetry`、`agent-run.ts` `streamAttempt` 的 `RectificationRunDiagnostic`、`turn-exit.ts` `finalizeSuccessfulTurnExit`、`engine-client.ts` `readV9EngineScoringIdentity`、校正面 `rectification-agentic-chat.tsx` 的 live 行。
|
||||
- 用户现象：产品 09-26 staging 真机：打字回答后，活动区一直是「正在分析 / 正在处理…」，要等很久（估计 25–90 s）才出正文，期间没有任何变化。
|
||||
|
||||
@@ -36,7 +36,7 @@
|
||||
| 任务书 | 进度 | 主题 | 状态 | 落点 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `TASK-rectification-dup-question-20260926.md` | `PROGRESS-rectification-dup-question-20260926.md` | **同一轮问题出现两次（BUG-1045，复发自 BUG-585，BUG-969 拼回题干、去重只在刷新路径）+ 同一道选择题连画两张（BUG-1046：提交失败不回滚本地已答 + 兜底问题块条件过宽；H2 漏收回合）**。先于 latency 单 | 已验收（Claude 09-26 直接执行：子代理复现 A 与 B-H1（选择题提交 409 / 网络错误不回滚本地已答）；Claude 变基到含 BUG-1043/1044 的 staging 后独立复验 tsc/lint 0、全量 3981 条失败名单与基线逐条一致、四路由 ○、gzip 不变） | `e4c1c7a3`（已部署 `f1d16405`，health 一致） |
|
||||
| `TASK-rectification-latency-20260926.md` | `PROGRESS-rectification-latency-20260926.md` | **每轮等待过长（BUG-1047）**：一轮打字回答串行 5 次开思考的模型调用，分类在开流前且无超时。产品定：收尾两步不动、分类保持思考只加 10 秒超时、发出后立即出确定性进度句并按阶段更新；补埋点；服务端无口吻优化须 A/B 逐位一致。排在 dup-question 之后 | 已验收（Claude 09-26 直接执行：子代理实现 D1–D4 与 D5 两项；Claude 用 Node 22 独立复验 tsc/lint 0、全量 4002 条失败名单与 Node 22 基线逐条一致（24 条均为 Docker/DB）、四路由 ○、gzip 不变。D5 第 1 项（探针复用）输出逐字节一致但触发冻结打分身份，Claude 建议暂不做） | `86ff9a40`（推 staging 待部署） |
|
||||
| `TASK-rectification-latency-20260926.md` | `PROGRESS-rectification-latency-20260926.md` | **每轮等待过长（BUG-1047）**：一轮打字回答串行 5 次开思考的模型调用，分类在开流前且无超时。产品定：收尾两步不动、分类保持思考只加 10 秒超时、发出后立即出确定性进度句并按阶段更新；补埋点；服务端无口吻优化须 A/B 逐位一致。排在 dup-question 之后 | 已验收（Claude 09-26 直接执行：子代理实现 D1–D4 与 D5 两项；Claude 用 Node 22 独立复验 tsc/lint 0、全量 4002 条失败名单与 Node 22 基线逐条一致（24 条均为 Docker/DB）、四路由 ○、gzip 不变。D5 第 1 项（探针复用）输出逐字节一致但触发冻结打分身份，Claude 建议暂不做） | `86ff9a40`（已部署 `8a409434`，health 一致） |
|
||||
| `TASK-rectification-session-title-result-20260922.md` | `PROGRESS-rectification-session-title-result-20260922.md` | **校正会话标题改写结果（BUG-1001）**：BUG-988 把副标题改成最后活动时间后，标题里的日期成了重复；而 BUG-929 删掉 `uniquifySessionTitle` 之后，`resolveSessionTitle` 对校正入口只返回 `生时校正 · M月D日`，**同一天多条标题完全相同**（真机截图：9/17 三条同名、9/16 两条同名、9/14 一天 5 条）；旧标题的钟点后缀是创建时间、副标题是最后活动时间，同一行两个对不上的时间。**产品 09-22 拍板**：D1 标题改为承载结果——有 `accepted_time`/`confirmed_time` 写 `生时校正 · HH:MM`，否则写 `candidate_range` 的 `生时校正 · HH:MM–HH:MM`（推翻 BUG-929 的日期口径，但「不得再加墙钟去重后缀」保留）；D2 存量批量重算（推翻 BUG-929「旧标题不批量改」，先例 `20260916020000_rectification_session_title_repair.sql`）；D3 今日节奏保留日期（我判定的例外）；D4 只在结果变化时改 title，`open` 路径不动（对 BUG-699 边界的有限扩展）。**红线**：任何写标题的路径都不得 bump `updated_at`（否则 13 条历史会话集体跳顶、毁掉 BUG-988）；标题算式必须只有一处实现（一个 SQL 函数，触发器与回填共用）——BUG-987/992 都栽在「两层规则各写一份」。T4 跨层对断不得让步。已 grep 出真正受影响的只有 7 个文件，Python 侧只查裸字符串、无需改。BUG 段 1001 起 | 已验收（Claude 09-25：单一 SQL 函数、不动 updated_at、手改名不覆盖、回填幂等） | `88fe67df`/`a94a1d67`（已部署） |
|
||||
| `TASK-rectification-convergence-20260830.md` | `PROGRESS-rectification-convergence-20260830.md` | 收敛重构 v2 | 已验收 | `3a4396a4`、`86ba17ee` |
|
||||
| `TASK-rectification-decision-authority-20260831.md` | `PROGRESS-rectification-decision-authority-20260831.md` | 决策权威归一与停止语义 | 已合入 | `9f011194` |
|
||||
|
||||
Reference in New Issue
Block a user