维护者确认: #2952 fix(desktop): 收口迟到 wake 终态泄漏的 pendingTaskWake 桥接

[MagicLizi]

PR #2952 触发了维护者确认门。

触发类别: product (命中 UI 路径: apps/desktop/src/renderer/lib/makerChatStore.ts)

涉及路径: Renderer 层 makerChatStore 的 pending task wake 桥接逻辑,修复侧栏 spinner 永久转圈

确认方式: 维护者直接在 PR 上 Approve 即放行;需要修改就 Request Changes,作者改完后重新 Approve。

---

关联 PR:#2952(作者 @mengfanyu9410-hub);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断

会话已完成却持续显示运行中会误导用户，并使依赖 busy 状态的侧栏、会话生命周期及输入预测门禁继续按“仍在工作”处理，因此值得修复。这是运行状态一致性修复，不涉及 spinner 组件、布局、样式或文案，也不需要新的产品交互决策。

当前 main 仍存在 pendingTaskWake 无法自愈的路径；#2952 复用既有延迟对账机制的方向合理，但最新方案仍有一个未被现有测试封住的 ABA 时序缺口，暂不建议直接 Approve。

行动

建议先对 #2952 Request Changes：

1. 不要把可增减的 pendingTaskWake 计数本身当作“代际”。增加一个单调递增、永不回退的 wake-bridge revision，或为每次桥接变化生成唯一 token；桥接置位和消费都必须推进 revision。
2. 快照请求前捕获 revision，响应落地时仅在 revision 完全未变化时允许收口；现有的主 turn idle、权威任务表为空、最小年龄及远程会话豁免条件可以继续保留。
3. 增加明确的 ABA 回归：请求前桥接为 1，请求在飞期间旧桥接被消费为 0，随后新终态再次置位为 1；让旧空快照在新桥接已超过 10 秒后返回，断言不得清除新桥接或产生 stopped transition。
4. 保留并运行现有泄漏收口、最小年龄、多 wake、权威表有活任务、正常 wake 消费和远程豁免测试；再执行 Desktop typecheck 及相关 sidebar/session 测试。
5. 先 resolve PR 当前仍未关闭的 3 条 review conversation，使自动审查恢复；上述竞态修正并验证通过后再由维护者 Approve。

源码核对

在 origin/main@951e1c5ae1afcf3904f5098e35f036c1a49f47e0 的 apps/desktop/src/renderer/lib/makerChatStore.ts 中：

• pendingTaskWake 是 wake 型任务从终态到 wake turn 启动之间的桥接计数。
• agent_task_update 对 wake 型任务发生真实的“非终态 → 终态”转换时计算 wakesAfterTerminal，并增加 pendingTaskWake。
• hasBackgroundAgentWork() 在本地会话中只要 pendingTaskWake > 0 或仍有 running wake task 就返回 true。
• running 快照使用 agentStatus.isRunning || hasBackgroundAgentWork()；因此主轮已经 Done 时，残留的桥接仍会持续撑住侧栏 spinner，并影响其他 busy 判定。
• 现有主要消费路径是 turn start 消费一个桥接，以及特定 wake-fail Done 分支消费一个桥接。主轮 Done 后若收到迟到终态，之后又没有 turn start 或 Done，桥接可以无限保留。

现有后台任务对账也无法覆盖该状态：

• scheduleBackgroundTaskReconcile() 使用 captureRunningClaudeTaskIds() 捕获仍为 running 的 Claude Code 任务，并在候选集为空时提前返回。
• seedBackgroundTaskSnapshots() 的 stale-running 对账只处理 taskUpdates 中仍为 running 的候选。
• 迟到事件对应的任务已经是 completed/failed，而 pendingTaskWake 又不是任务表中的 running 条目，所以不会进入现有收口路径。

因此，#2951 所描述的核心泄漏链路在当前 main 中确实仍然存在，也没有发现其他已合入修复覆盖它。

对 #2952 最新方案的评估

PR 增加了以下防护：

• 主轮 Done 后置位桥接时调度延迟对账；
• 即使没有 running task，只要桥接非零也允许发起对账；
• 要求主 turn 不在运行、main 快照中没有 wake 型活任务、桥接达到 10 秒最小年龄；
• 请求前捕获 pendingTaskWake，响应落地时要求当前计数与捕获计数相同；
• 沿用既有 sticky remote 多阶段豁免。

这些条件能处理静止泄漏，也能阻止简单的 1→2 或 1→0 在飞变化，但“当前计数相等”不等于“状态期间没有变化”。仍存在以下交错：

1. 对账请求前捕获 pendingTaskWake = 1；
2. 旧 wake turn 启动，消费桥接：1→0；
3. 另一个终态置位新桥接：0→1；
4. main 快照响应延迟，直到新桥接也超过 10 秒；
5. 旧响应返回空表，当前计数仍等于捕获值 1；
6. 对账把新的合法桥接当成旧桥接清除。

pendingTaskWakeArmedAt 会在新置位时刷新，因此 10 秒闸可以延后误收口，但不能消除该 ABA：只要旧响应再晚一些返回，年龄条件仍会通过。现有“请求在飞窗口内新置位”与“多 wake 依次消费”测试若只覆盖计数变为不同值，就不能证明 1→0→1 安全。

这类误收口虽然可能被后续 turn start 重新撑起 running，但仍会造成短暂假空闲，并可能触发一次错误的完成通知。既然可以用单调 revision 在 Renderer 内低成本消除，就不应把它作为已接受的正常行为。

风险与边界

现场材料证明了两个 fork 会话在完成后持续转圈 20 分钟以上，但 v0.1.55 缺少该路径的事件级日志，当前仍无法确定迟到终态究竟来自：

• 父/子或兄弟会话间的事件误投；
• 重连后的终态重放；
• 正常但异常缓慢的 task notification / wake turn。

因此，Renderer 对账适合作为防御性自愈；“跨会话误投”目前仍是待验证根因，不能据此认定 main 路由已经有问题。后续若能取得 task ID、source session ID、父会话 ID、main 任务表归属以及 terminal-to-wake 时间线，再决定是否需要单独修复事件路由或提供更强的 pending-continuation 权威信号。

相关记录

• 侧栏 spinner 在会话完成后永久转圈:迟到的 wake 任务终态泄漏 pendingTaskWake 桥接,无自愈路径 #2951：直接故障记录。两个实际 fork 会话在主轮完成后仍转圈 20 分钟以上；源码链路得到确认，但由于缺少事件级日志，尚不能区分误投、重放与合法长空窗。
• fix(desktop): 收口迟到 wake 终态泄漏的 pendingTaskWake 桥接,修复侧栏 spinner 永久转圈 #2952：当前直接修复 PR。方向和作用域合适，尚未合并；需要先消除计数代际的 1→0→1 ABA 竞态。
• fix(desktop): 后台任务终态事件丢失后按 main 快照对账收口 #2003：已合入的 stale-running 对账基础设施，建立了活动熄灭后延迟拉取 main 快照、请求前候选捕获和远程会话多阶段豁免。当前 PR 可以复用该机制，但 fix(desktop): 后台任务终态事件丢失后按 main 快照对账收口 #2003 只收口仍为 running 的任务条目，并未覆盖 pendingTaskWake，因此当前问题不是重复修复。

[MagicLizi]

维护者确认已通过,讨论结束,PR 恢复正常推进。关联 PR:#2952(https://github.com/makecindy/cindy/pull/2952)。本 issue 由 review-pr 流程自动关闭。