17 lines
4.8 KiB
Markdown
17 lines
4.8 KiB
Markdown
|
# 多 task 串行推进时 task2 无法启动（onPreviewReadyForNextTask 时序缺陷）
|
|||
|
|
|
|||
|
|
日期：2026-06-30
|
|||
|
|
文档路径：document/development/2026-06-30/dev-logs/bugs/multi-task-next-task-blocked-by-preview-ready-timing.md
|
|||
|
|
|
|||
|
|
## 修复记录
|
|||
|
|
- 11:18：记录 bug 修复：用户在 AI 工作台输入"出差申请 + 招待费报销"等多 task 时，task1（出差申请）保存草稿/提交成功后，task2（招待费报销）完全无法启动，界面停在"申请草稿已保存"。
|
|||
|
|
- Git 提交检查：`git fetch --all --prune` 成功；upstream `origin/main`；`HEAD..@{u}` 未发现 upstream 新提交；`@{u}..HEAD` 未发现本地 ahead 提交。工作区改动仅为本次 3 个源文件 + 2 个测试文件（另有一个预先存在的未提交改动 `server/rules/finance-rules/公司通信费报销规则.xlsx`，与本次无关）。
|
|||
|
|
- 根因：`onPreviewReadyForNextTask` 回调在 task1 申请核对表**刚生成、用户还没看、还没点保存草稿**时就立刻触发 `startModelPlannedNextTask`，提前把 task2 招待费报销拉起（`startAiExpenseDraft` 会 push 一条"选择费用报销"用户消息 + 报销 prompt）。两条流程的消息和状态互相打架，用户再在 task1 上点保存草稿时 `onApplicationActionCompleted` 又试图拉起 task2，但 task2 状态已被前面 `onPreviewReadyForNextTask` 搞乱，最终表现为"完全无反应"。运行时复现脚本时序铁证：预览生成后立即出现 `!!! onPreviewReadyForNextTask 触发(task1预览刚生成,用户还没操作)`，与串行推进的正确语义（task1 完成后才推进 task2）冲突。这是早期实现的残留——引入 `onApplicationActionCompleted`（task1 完成后触发）后，`onPreviewReadyForNextTask` 职责重叠且时序错误。
|
|||
|
|
- 修改（前端 web，3 个源文件）：
|
|||
|
|
- `web/src/composables/workbenchAiMode/useWorkbenchAiApplicationPreviewFlow.js`：删除 `startAiApplicationPreview` 预览生成后的 `else if (onPreviewReadyForNextTask ...)` 提前推进分支（原 L622-L628），并加注释说明 task2 推进统一交给 `onApplicationActionCompleted` 在 task1 真正完成后触发。`executeInlineApplicationPreviewAction` 里 L466 的 `actionCompletedHandler` 回落逻辑保留不动（手动点保存草稿走 actionRouter 不传 options 回调，回落到模块级 `startModelPlannedNextTask`，这是正确的续跑路径）。
|
|||
|
|
- `web/src/composables/workbenchAiMode/usePersonalWorkbenchAiMode.js`：`startModelPlannedApplicationPreview` 调用 `startAiApplicationPreview` 时删除 `onPreviewReadyForNextTask: startModelPlannedNextTask` 一行，只保留 `onApplicationActionCompleted: startModelPlannedNextTask`（原 L769）。
|
|||
|
|
- `web/src/composables/workbenchAiMode/useWorkbenchAiActionRouter.js`：`ai_application_confirm_intent`（低置信确认按钮）分支删除 `onPreviewReadyForNextTask` 回调，只保留 `onApplicationActionCompleted`（原 L99-L104），消除低置信路径的同样时序缺陷。
|
|||
|
|
- 操作：先写复现脚本 `/tmp/repro-timing.mjs`（applicationFlow + 两个回调）锁定时序根因——修复前预览生成后立即触发推进回调，修复后无提前触发；再按计划小步改 3 个源文件 + 2 个测试文件；未提交（工作区有预先存在的无关 xlsx 改动，未自动提交）。
|
|||
|
|
- 验证：宿主机 node v22.22.3 跑 `node --test web/tests/workbench-ai-intent-planner-model.test.mjs web/tests/workbench-ai-action-router.test.mjs web/tests/workbench-ai-application-context-submit.test.mjs` 通过 27/27（含新增的时序回归用例 `workbench application preview does not continue next task until draft is saved or submitted`：断言预览生成时 `continuedTasks.length === 0`、保存草稿后才推进 task2 且走模块级续跑回调、自动续跑时不展示重复的"继续处理"按钮）；`npm --prefix web run build` 通过（3.97s）；复现脚本 `/tmp/repro-timing.mjs` 修复后事件序列只剩用户消息、无提前推进；真实 `http://localhost:5173/api/v1/steward/plans` 与 `/api/v1/steward/plans/stream` 采样确认该句子仍返回 `expense_application` + `reimbursement` 两个 task（后端拆分正确，本次未动后端）。
|
|||
|
|
- 影响：用户输入框提交"2月20-23日，去上海出差辅助国网仿生产服务器部署，并且报销昨天的上午招待费2000元"等多 task 时，task1 出差申请核对表生成后干净停下等用户操作，用户点保存草稿/直接提交成功后自动进入 task2 招待费报销（预填金额/时间/事由），不再出现两条流程打架导致 task2 完全无反应的问题。不影响后端、单 task 场景、autoSaveDraft 路径（它走 `executeInlineApplicationPreviewAction` 完成后触发 `onApplicationActionCompleted`，链路不变）；低置信确认按钮路径也同步修复。
|