feat(suspend): 会话正在产出回复时延迟挂起而非切断

[xu4wang]

📌 2026-08-09 更新：已按 review 拆分。 commit 2（挂起前 flush transcript 桥）已从本 PR 移除 —— 它的产物会被 daemon 的 generation fence 确定性丢弃，需要在那道 fence 上开定向例外才能落地，值得单独一个 PR 带 daemon 侧行为测试来做。随它一并消失的还有 cold-refork race（那个窗口正是 flush 推迟 destroySession 500ms 引入的）。另补一个提交把 pendingSuspendReason 绑定到 worker generation，修掉 claim 跨代残留。详见本 PR 的讨论区回复。

另：下文关于 screenshot_uploaded 「陈旧 idle 来自被替换的旧 ChildProcess」的措辞不准确 —— 外层统一 fence 已把 stale worker 的消息挡在 switch 之外。ownsWorkerSession 谓词真正挡的是 queueMicrotask 延迟兑现造成的跨代窗口（fence 在消息入口同步检查，兑现却在微任务里执行，其间 ds.worker 可能已换代）。

---

改了什么

botmux suspend 在会话正在产出回复时会直接杀掉 worker，把那一轮回复丢掉。本 PR 把它改成：正在忙的会话先排队，等它自己结束后自动挂起——语义从「立即挂起」变成「最终挂起」，不漏任何会话。

三个 commit，互相独立、可分别回滚：

1. feat(suspend) —— 排队 + 兑现机制（daemon 侧）
2. fix(worker) —— 挂起前 flush transcript 桥里已就绪的回复（worker 侧）
3. fix(cli) —— --dry-run 区分「daemon 不在线」与「读不到」（live 验证暴露，见下）

为什么

POST /api/sessions/:sessionId/suspend 此前只有四道守卫（session_not_active / session_transferring / adopt / backend_not_suspendable），没有任何 busy 检查。对比同文件的 POST /api/host-overload/sweep 就有 if (ds.lastScreenStatus !== 'idle') continue;——这个概念在代码库里已经存在，只是没用在 suspend 路由上。

在按凭证轮换周期调用 suspend all 的部署里，这意味着每个周期都会打断若干个正在生成的回复。31 小时探针采样显示并发 busy 会话数 p99=4 / max=5。

延迟兑现对凭证轮换而言严格优于立即切断：正在跑的那一轮本来就持有旧凭证，切断它并不能让那一轮用上新凭证，只是白白丢掉一次回复；两种做法对「该会话何时开始用新凭证」的结果相同（都是下一轮）。因此直接改默认，不加开关。

完整设计（含决策取舍、边界情况表、残留窗口）见新增的 docs/design/deferred-suspend.md。

机制

排队：路由收到请求时若 lastScreenStatus 为 working/analyzing（且 backend 可挂起），不杀 worker，在 DaemonSession 上记 pendingSuspendReason，返回 { ok: true, suspended: false, reason: 'deferred' }。

兑现：screen_update / screenshot_uploaded 把状态写成 idle/limited 后触发 runPendingSuspendIfSettled。

三个不显然但必要的正确性细节：

• 兑现必须 queueMicrotask 推迟一拍。 suspendWorker 是同步的且会清空 ds.worker 与 ds.lastScreenStatus，而同一个 handler 在赋值之后还要读这两个字段做回合收尾——recordUsageForDaemonSession 与 finishTurnReactions（✋→✅）都门控在 lastScreenStatus === 'idle' || 'limited' 上，同步挂起会让它们整段跳过；emitSessionStateTransitionHook 会把新状态报成 undefined；末尾 buildStreamingCard 也拿到 undefined。同步调用等于为了不切断回复、反手切掉了这一轮的收尾记账。（用的是该文件既有惯用法：同一段里 queueMicrotask(cb.enforceLiveSessionCap) 的注释正是「Defer until this screen_update has finished using process state」。）

• 必须带 generation 判定。 screenshot_uploaded 这个 case 没有 ownsLifecycleMutation() 守卫（screen_update 第一行就有），它今天就无门槛地写 lastScreenStatus。把「写状态」升级成「杀 worker」之后：旧 worker 被 refork 替换 → 它退出前排队的 screenshot_uploaded(idle) 晚到 → 覆写成 idle → 微任务看到新 worker 还活着 → 把刚起来的新 worker 挂了。新 worker 若正在产出，就是原样复现本 PR 要消灭的截断 bug。因此陈旧 checkpoint 保留标志直接返回，只有当前 generation 有资格消费它。

• 只在 suspendWorker 成功时清标志，且 transfer 拒绝后要显式重试。 传入的是纯 generation 判定 ownsWorkerSession 而非 ownsLifecycleMutation（后者把「不在 transfer 中」也折了进去）：routing transfer 是暂时拒绝，该由 suspendWorker 自己那道守卫判。而会话安静下来后屏幕分析器就不再发 screen_update（只在 changed || status 变化 时发），所以光保留标志可能等不到下一个 checkpoint——拒绝后用已导出的 deferUntilSessionTransferSettled 注册重试。

worker 侧 flush（第二个 commit）：final_output 由 transcript 驱动、触发挂起的 idle screen_update 由屏幕分析器驱动，两个独立生产者没有顺序保证。挂起那一刻回复可能还躺在 bridge 队列里，而 case 'suspend' 的自身拆解会把它毁掉两次：stopBridgeWatcher() 调 clearPending()，process.exit(0) 又丢掉 process.send 只排队还没写出的 IPC。改为先 drain 两条桥（CLI 还活着时 transcript 才完整），再追一条 suspend_ready 走 sendAndFlush 做写屏障（process.send 是 FIFO，回调触发即前面的 final_output 已落到管道上）。

这是尽最大努力而非保证：等待有界 500ms，超时被选中时屏障未成立、仍会丢。不能改成无限等——daemon 在发出 suspend 时就 arm 了 2s SIGTERM backstop（WORKER_SIGTERM_BACKSTOP_MS），无限等根本不是无限等，只会把预算耗光、让 destroySession 与 cleanup 来不及跑，backing session 和 CLI 留着不释放，挂起要回收的内存一点没回收。

影响面

• 只改 suspend 路由。idle-worker-sweeper 与 host_overload_sweep 本来就有 busy 守卫，未改动。
• 非 busy 会话的路由行为逐行不变：排队条件写成 busy && isSuspendableBackendType(...) 的合取式而非独立前置守卫。写成前置 return 会改掉非 busy 路径——isSuspendableBackendType(undefined) 返回 false，而 test/dashboard-ipc.test.ts 里那条 mock 掉 suspendWorker 的既有用例 fixture 没有 initConfig。合取式下不可挂起的 backend 照旧穿透到 suspendWorker 的 409。
• worker 侧 flush 对所有 CLI 生效（两条桥：Claude 走 bridgeQueue，codex/grok/traex/pi/hermes/mtr 走 codexBridgeQueue），并顺带修好 idle-worker-sweeper / host_overload_sweep 两条既有挂起路径的同一个洞。
• 新增 suspend_ready 消息 daemon 侧无 handler：它是写屏障不是命令；worker-pool 的消息 switch 没有穷尽性 default，会被自然忽略。
• 不引入新配置项或环境变量。不做持久化（daemon 重启丢失排队状态，下一个 suspend all 周期重新排队）。

测试验证

新增 26 条用例（3 个文件）

$ pnpm vitest run --project unit test/deferred-suspend.test.ts \
    test/ipc-suspend-route.test.ts test/worker-suspend-output-flush.test.ts

 ✓  unit  test/worker-suspend-output-flush.test.ts (5 tests)
 ✓  unit  test/deferred-suspend.test.ts (13 tests)
 ✓  unit  test/ipc-suspend-route.test.ts (8 tests)

 Test Files  3 passed (3)
      Tests  26 passed (26)

• test/deferred-suspend.test.ts —— 兑现半边。仿照同文件既有的 __testOnly_deliverFinalOutput 导出 __testOnly_runPendingSuspendIfSettled 做真行为断言（mock session-store / dashboard-events / logger，写法照抄 test/worker-suspend.test.ts）：working/analyzing 空操作且标志必须留着、idle/limited 兑现、worker 已 killed 只清标志、不重复挂起、reason 真的被透传（断言 mock 的 logger 收到该 reason）、ownsGeneration 真/假两条、suspendWorker 拒绝时保留标志、transfer 结算重试的接线。
• test/ipc-suspend-route.test.ts —— 排队半边，起真 IPC server + vi.spyOn（写法照抄 test/ipc-close-route.test.ts）：deferred 返回值且没有调用 suspendWorker、idle/limited 仍立即挂起、状态 undefined 不排队、幂等分支仍返回 no_live_worker 不被误判为 deferred、backend_not_suspendable / adopt_suspend_unsupported 两道守卫都排在排队之前。
• test/worker-suspend-output-flush.test.ts —— worker 侧接线。worker.ts 的 IPC handler 模块级副作用太重、单测里无法独立驱动，按仓库既有惯例（见 test/worker-pipe-initial-screen-order.test.ts）用源码断言钉住顺序与关键参数：flush 排在 stopBridgeWatcher / destroySession 之前且带 await、两条桥都 drain 且 codex 那条精确匹配 { signalIdle: false }、写屏障位置在两个 drain 之后、等待有界且预算 < 2000ms、两个 drain 各自独立 try/catch。文件头已如实注明这是接线测试而非行为测试及其局限。

全量回归（前后对照）

$ pnpm vitest run --project unit
 Test Files  6 failed | 822 passed | 4 skipped (832)
      Tests  14 failed | 13277 passed | 37 skipped (13328)

14 条失败已用 git stash 拉出干净基线逐条对照确认与本改动无关：其中 13 条（capabilities / command-handler / exact-chat-grant-cli / session-picker-responsive / session-ready-cli）在 stash 掉全部改动后照样失败；余下 1 条 cost-calculator-cache 只在全量并行下失败，单独跑 49 passed，是负载相关 flake 且与本改动文件无交集。

pnpm build 干净通过。

开发过程中曾引入一条真回归（把 backend_not_suspendable 写成独立前置守卫，打挂 test/dashboard-ipc.test.ts 的既有用例），已按上文「影响面」改成合取式修正，现该文件 115 条全绿。

Live 端到端验证（已完成）

已部署到一台真实多 bot 机器（11 个 pm2 进程）跑完 docs/design/deferred-suspend.md §7 全部五步。验证对象就是执行验证的那个会话自己——它在生成回复的过程中被 botmux suspend all 命中：

$ botmux suspend all
⏳ 已排队（正在回复，完成后自动挂起）: cdaf7a59  docs/design/deferred-suspend.md

完成：挂起 0 个，排队 1 个，跳过 515 个。

随后 daemon 日志（同一毫秒的三行，时序完整）：

[cdaf7a59] Worker + CLI suspended (manual_suspend); session stays active, cold-resumes ...
[cdaf7a59] Deferred suspend fulfilled (manual_suspend) after turn completed
[worker:cdaf7a59] Suspend requested

§7 步骤	结果
2. 忙时 suspend → 输出 ⏳ 已排队	✅ 见上
3. 回合结束 → Deferred suspend fulfilled	✅ 日志原文
4. 变 dormant → 下条消息冷启动 --resume	✅ worker PID 已更换，会话上下文完整续回
5. 关键回归：那一轮回复完整送达、未被截断	✅ 旧代码会在此处杀 worker 丢掉整轮回复

补充验证：受控计时 + transcript 驱动的投递路径

上面那次是被 suspend all 撞上的。随后又做了两组受控验证。

(a) 延迟本身是真的，不是只贴了个标签。 在会话正在产出时发起挂起，然后持续观察 worker：

T0 = 03:14:09  发起挂起 → ⏳ 已排队
03:14:29 +10s  PID=22044 存活   03:15:04 +40s  PID=22044 存活
03:14:41 +20s  PID=22044 存活   03:15:15 +50s  PID=22044 存活
03:14:52 +30s  PID=22044 存活   03:15:27 +60s  PID=22044 存活
03:15:49 +100s PID=22044 存活
03:16:25.618   Deferred suspend fulfilled  ← 回合结束才兑现，延迟 2 分 16 秒

PID 自始至终未变（同一进程，未被杀也未被替换），且排队窗口内 daemon 日志中没有任何
Worker + CLI suspended。同时验了三条分支：排队期间重复请求 → 幂等仍报 ⏳ 已排队；
对已 dormant 的会话 → 本就无存活 CLI（目标态已达成），未被误判为 deferred（正是单测
钉的那条不变式）；不存在的 id → 正常报错。

(b) 真正重要的一次：transcript 驱动的 final_output 路径。

先踩到一个坑并因此改进了测试设计——第一次注入任务后日志显示：

Bridge fallback suppressed for turn trg_4050 (model called botmux send within window)

即只要模型调了 botmux send，transcript 兜底路径根本不会触发。这解释了为什么此前所有
验证都碰不到这条路。于是改为明确要求被测会话本轮不调用 botmux send，让 transcript
兜底投递，再在其产出过程中挂起：

03:24:06  status=working → 立即发起挂起 → ⏳ 已排队: 1dc937ba
03:24:06 ~ 03:24:28      status 持续 working（23 秒，worker 未被杀）
03:24:27.478  Bridge final_output forwarded (turn 1b7dbc70, 462 chars, kind=bridge, attempt 1)
03:24:28.622  Worker + CLI suspended (manual_suspend)
03:24:28.622  Deferred suspend fulfilled (manual_suspend) after turn completed
03:24:29      status=dormant

kind=bridge 即 transcript 驱动的 final_output，462 字符完整投递。而挂起请求发生在
03:24:06 —— 旧代码会在那一刻杀掉 worker，而这条回复要 21 秒后才存在，会被整条丢掉。
这是本 PR 核心承诺在最相关路径上的直接证据。

commit 2（worker 侧 flush）的验证边界 —— 不夸大

确认被执行：Suspend requested 说明进了 case 'suspend'，flush 排在其中所有 teardown
之前；全机日志里 Suspend (bridge|codex bridge) drain failed 计数为 0，两条 drain 从未
抛错、也未阻塞挂起。

但正向场景至今未被观测到。 看上面 (b) 的时序：final_output 在 :27.478 就已转发，
worker 到 :28.611 才收到 suspend —— 回复比挂起早 1.1 秒，flush 执行时队列里依然没有
待发内容。flush 要兜的是更窄的竞态（idle 边沿那一刻 final_output 还没 drain 出来），
正常路径撞不上，稳定复现需要人为制造 drain 延迟（故障注入）。

所以 commit 2 现有证据是「执行了、不出错、不阻塞」，而不是「已证明救回过回复」。
它是给那条窄缝兜底的防御性改动，且独立可回滚（删掉它排队机制照常工作）。

Live 验证暴露的缺陷（commit 3）

单测和两轮定向 review 都没发现，因为它只在真实多 bot 环境里显形：

--dry-run 把 20/516 个会话报成 ? 未知（daemon 状态读不到），而它们的真实结果是确定可知的「跳过」——那是 cli_listener_status / cli_listener_run 两个伪 app id 下的 Message Listener Preview 会话，压根没有对应的在线 daemon，真实循环在发请求之前就会因同一条件跳过。原实现把「daemon 不在线」和「daemon 在线但 /api/sessions 读失败」混成同一个 undefined，于是把本来能预告准的结果一并降级成了「未知」——这和瞎猜一样是失职，只是失职的方向相反。

改为三态 Lookup（row / no_daemon / unreadable），并补上真实循环里排在 daemon 查找之前、此前漏掉的 !larkAppId && online.length > 1 那道跳过。

同机复验，改前 → 改后：

改前： 20 个 ? 未知（daemon 状态读不到，无法预告）  + 结尾 warning
改后： 22 个 · 将跳过（daemon 不在线: cli_listener_status / cli_listener_run）

现在 518 个目标零「未知」，结尾 warning 也不再出现：
 495 · 将跳过（本就无存活 CLI）
  22 · 将跳过（daemon 不在线: cli_listener_*）
   1 · 将排队（正在回复，完成后自动挂起）

与真实 suspend all 的实际结果（495 无存活 CLI + 20 daemon 不在线 + 1 排队）逐类吻合。

注：commit 3 靠 live 复验，没有配套单测——cmdSuspend() 是直接读 session store、拿全局 daemon 列表并打 console.log 的 CLI 入口，为它补单测需要先把这段分类逻辑抽成纯函数。分类函数本身（predictSuspend）已经是纯函数、具备可测形状，但本 PR 未做这一步重构。

已知残留（已在设计文档记录）

• worker 侧 drain 用的是 drainEmittable({ terminalBoundary: true })，若这一轮的 terminal 行在 drain 那一刻还没落到 transcript 里仍会漏——窗口从秒级压到微秒级，但未归零。彻底归零需要让挂起等一个显式的 turn-terminal 信号，属另一个设计。
• screenshot_uploaded 陈旧消息仍会先无守卫地覆盖 lastScreenStatus（既有行为）。微任务那条路已由 generation 判定堵死，但还剩一个更窄的窗口：旧 worker 写入 idle 后、新 worker 下次状态更新前，此时调 suspend 路由会看到 idle 从而立即挂起新 worker 而非 deferred。彻底修法是给该 case 整体加 generation 守卫，会改动它对 currentImageKey / usage 的既有行为，故未纳入本 PR。
• --dry-run 复刻不了路由的第一道 isSessionTransferring 守卫（/api/sessions 的行不暴露 transfer 状态），正在 transfer 的会话会被预告成「排队/挂起」而实际返回 session_transferring。transfer 是短暂窗口，为一个 dry-run 预告给 SessionRow 加字段不成比例；已在代码注释与设计文档边界表标明，日后行里若有该状态，在 adopt 之前补一条分支即可。
• live 验证共取得 3 个 deferral 样本（suspend all 撞上一次、受控计时一次、transcript 投递路径一次），覆盖了 working 状态、幂等重复请求、已 dormant 会话、无效 id 四种情形。但 limited 状态的兑现、以及 adopt / pty 两条拒绝分支仍只有单测覆盖、无 live 样本——它们需要被限流的会话和 pty backend 会话，本次没有现成样本。
• commit 2 的正向场景无 live 证据（详见上文「验证边界」一节）：它兜的是 idle 边沿 final_output 尚未 drain 的窄竞态，正常路径撞不上，稳定复现需故障注入。已决定不做故障注入，按现状如实标注。

[deepcoldy]

Review 结论:🔴 需要改动(1 个 blocking + 2 个待处理项)

排队主机制(commit 1)思路是对的,实现也扎实——正在产出的会话记 pendingSuspendReason、转入 idle/limited 再兑现,不切断当前轮。但 commit 2 的核心承诺在 daemon 侧拿不到,不能直接合。

Blocking:commit 2 的 flush 产物会被 daemon 确定性丢弃

时序是闭合的,不是概率窗口:

1. suspendWorker 在 src/core/worker-pool.ts:2246 向 worker 发 { type: 'suspend' },紧接着 :2252 在同一同步调用栈内执行 ds.worker = null(中间只有 armWorkerKillBackstop,无 await、无 yield)。
2. worker 要等收到该消息后,才在 src/worker.ts:12980 执行 flushBridgeOutputBeforeSuspend(),drain 并发出 final_output / suspend_ready。
3. 等这些消息回到 daemon 时,ds.worker 早已是 null。message handler 在 switch 之前有一道统一 fence:src/core/worker-pool.ts:4966 的 if (ds.worker !== worker) return,会在进入 case 'final_output' 之前就把它丢弃;suspend_ready 同样被丢。
4. 即便绕过外层 fence,deliverFinalOutput(..., ownsLifecycleMutation) 在 :6776 首行仍会因退休 worker 不再拥有 session 而 return(ownsWorkerSession 里 ds.worker === worker 必假)。

所以这不是「正向场景尚未观测」,而是当前接线下正向场景无法成功。现有 worker-suspend-output-flush.test.ts 只对 worker 侧做源码顺序断言,完全没跨过 daemon 的 generation fence,因此 5/5 通过也发现不了。

建议修复时补一条真行为测试:挂 fake worker → 调 suspendWorker → 让退休 worker emit final_output → 断言该 turn 的 sessionReply 仍发生。实现上需要精确授权「正在 suspend 的那一个 worker」的 terminal output,不能泛化放开 stale-worker fence。

待处理项 1:cold-refork race(本 PR 新引入的窗口)

对比 master 的旧 case 'suspend':此前是 stopBridgeWatcher 之后立即 destroySession;本 PR 在中间插入了 await flushBridgeOutputBeforeSuspend()(有界 500ms)。daemon 侧 ds.worker = null 是同步立即的,但旧 worker 销毁 backing tmux pane 被推迟了最多 500ms。这期间若有新输入进来,daemon 会立即 forkWorker,新 worker 可能 reattach 同名 pane,随后被旧 worker 延迟到期的 destroySession 一并 kill。两阶段 handshake / retiring 状态可同时覆盖这个窗口。

待处理项 2:pendingSuspendReason 可跨退休生命周期残留

全仓只有 runPendingSuspendIfSettled 的 :2339 / :2346 两处清这个标志。若排队后由 /cd(command-handler.ts:1424)、读隔离切换(session-manager.ts:306)先成功挂起,或 worker 直接崩溃,兑现函数没机会运行,标志会残留到下一代 worker;下一代到 idle 时会被额外再挂一次。no_live_worker 路由也不会清它。这与新增测试注释里「worker 崩溃/被其它路径抢先挂起、目标态已达成应清标志」的意图不一致。建议把 claim 绑定到目标 worker generation,或在该 generation 成功 suspend/exit、目标态达成时统一消费。

一处文档校正(非 blocking)

PR 描述里「screenshot_uploaded 陈旧 idle 来自被替换的旧 ChildProcess」这个叙事不成立::4966 的 switch 外统一 fence 已先丢弃旧 worker 的全部消息,陈旧消息进不到该 case。该 case 缺少内部 ownsLifecycleMutation 仍是既有一致性问题,但不是描述的跨 worker 窗口。ownsWorkerSession 作为防御可保留,但正确性主要由外层统一 fence 保证。

---

三个 commit 各自独立可回滚。想请你定个方向:是重做 commit 2(让 flush 产物能真正跨过 daemon 接收边界)+ 补 daemon 侧行为测试后整体再看,还是先把 commit 2 拆出去、只合排队主机制 + CLI dry-run 修复?

验证:pnpm build ✅ / tsc --noEmit ✅ / 新增 3 测试文件 26/26 ✅ / 全量回归无本 PR 相关新增失败。

[xu4wang]

感谢 review，三条实质意见都成立，已按「拆分」方向重做。分支已 force-push（b512ac39 → 4f6a5e53，rebase 到最新 origin/master）。

已做的处理

1. blocking —— commit 2 已从本 PR 移除

fix(worker): 挂起前先 flush transcript 桥里已就绪的回复 整个撤掉，本 PR 现在只剩排队主机制 + CLI dry-run 修复。

我独立核实了这条：w.send({ type: 'suspend' }) 之后在同一同步调用栈内就 ds.worker = null（中间只有 armWorkerKillBackstop，无 await）；worker 要收到消息后才 await flushBridgeOutputBeforeSuspend()；而 message handler 在 switch 之前就有 if (ds.worker !== worker) return。时序确实是闭合的，产物必然被丢弃 —— 不是「正向场景尚未观测」。

那组测试之所以 5/5 绿还发现不了，是因为它只对 worker 侧做源码顺序断言，完全没跨过 daemon 的接收边界。这个教训我记下了。

要让 flush 真正落地，需要在那道 fence 上开一个「正在 suspend 的这一个 worker」的定向例外 —— 那道 fence 护着 cards / tokens / readiness / durable turn state，值得单独一个 PR 连同 daemon 侧行为测试一起做，不该挂在这里拖住主机制。

2. 待处理项 1（cold-refork race）—— 随 commit 2 一并消失

那个窗口正是 flush 把 destroySession 推迟最多 500ms 引入的。commit 2 撤掉后，stopBridgeWatcher → destroySession 恢复为原来的紧邻顺序，窗口不复存在。

3. 待处理项 2（pendingSuspendReason 跨代残留）—— 已修

新增 commit fix(suspend): 排队的挂起请求绑定 worker generation，不再残留到下一代。

确认了问题的准确形态：清除逻辑其实写了（if (!ds.worker || ds.worker.killed) → 丢标志），缺的是触发它的时机 —— 那段代码长在 runPendingSuspendIfSettled 里，而该函数只被 screen_update / screenshot_uploaded 两个 checkpoint 调用，会话安静下来后就再也不会运行。

改法：

• 新增 pendingSuspendGeneration，IPC 路由排队时绑定当前 generation；
• 新增 clearPendingSuspendClaim()，在 suspendWorker 成功与 worker exit 两处统一消费 —— 只要那一代停止运行，目标态即达成，无论由哪条路径达成（/cd、读隔离切换、idle sweeper 都不路过 checkpoint）；
• runPendingSuspendIfSettled 增加 generation 门控作兜底：claim 属于更早的 generation 时就地消费，绝不挂起它从未指向过的 worker。

暂时性拒绝（routing transfer / 不可挂起 backend）仍保留 claim 及其 generation，语义不变。

新增 4 条行为测试（不是源码断言）：任何成功的 suspend 都会消费 claim、被拒绝时 claim 与 generation 一并保留、claim 属于更早 generation 时不挂新 worker、同代时照常兑现。做过注入回归：去掉 suspendWorker 里的消费点、或去掉 generation 门控，对应用例分别失败，恢复后全绿。

一处想补正的：screenshot_uploaded 那段

陈旧消息进不到该 case……不是描述的跨 worker 窗口

PR 描述的措辞确实错了，我会改：外层 fence 的确把 stale worker 的消息全挡在 switch 之外，「陈旧 idle 来自被替换的旧 ChildProcess」这个说法不成立。

但由此推出的「不是跨 worker 窗口」我认为不完全对，关键在这一行：

queueMicrotask(() => runPendingSuspendIfSettled(ds, ownsWorkerSession));

外层 fence 是消息入口的同步检查，而兑现被推迟到微任务。从 fence 通过到微任务执行之间，handler 剩余的同步代码还在跑，ds.worker 完全可能已经换代。可踩到的场景：两条消息在同一 tick 内都合法通过 fence、各自 queueMicrotask；第一条的微任务里 suspendWorker 成功、ds.worker 置空、随后 refork 装上新 worker；第二条微任务这时才执行，看到的是一个全新的 worker —— 没有 ownsWorkerSession 谓词的话，正好把刚起来的 worker 挂掉。

而兑现必须推迟本身也是必要的（同步调会让同一 handler 后面的 usage 记账、✋→✅、状态 hook、末尾卡片整段踩空），所以不能靠去掉 queueMicrotask 来消解。

所以谓词挡的是一个由延迟兑现制造的真实窗口，而不只是既有一致性问题的顺手补丁。如果这个理解有偏差，请指出。

验证

• npx tsc --noEmit ✅
• test/deferred-suspend.test.ts 17 passed（新增 4 条）、test/ipc-suspend-route.test.ts 8 passed
• 全量 unit 做了基线对照：把分支 reset --hard origin/master 跑同一组失败文件得 20 failed / 305 passed（8 个文件）；带本 PR 改动跑同一组 同样 20 failed / 305 passed，文件集合一字不差。这批是基线自带的不稳定集成测试，与本 PR 无关。