关停期投影注销竞态：一次可预期的清理异常把整个 web 服务打死

① 注册（是 ctx.effect，随 ctx 一起被拆）
   dsh-agent-loop/lib/index.js:1559
     ctx.sessionProjections.register(inboxProjectionDefinition)
   实现 dsh-session-projection/lib/index.js:68-102
     register(definition) {
       …
       const dispose = this.ctx.effect(function* () { … }.bind(this),
                                       "sessionProjections.register()");
       return () => void dispose();
     }
   ⇒ disposer 在**该 fiber/ctx 被 dispose 时**运行，把该 key 从 registrations 里删掉。

② 读（缺 key 就返回 undefined，不抛）
   dsh-session-projection/lib/index.js:127-131
     stateOf(session, key) {
       const registration = this.registrations.get(key);
       if (registration === void 0) return void 0;      ← ★ 关键返回
       …
     }

③ 关停：ctx 被 dispose ⇒ ① 的 disposer 运行 ⇒ registrations 里没有 "inbox" 了。

④ 仍在飞的 abort（在拆完之后才跑）
   dsh-subagent-in-process-driver/lib/index.js:200   AbortSignal.onAbort
     → dsh-agent-loop/lib/index.js:817                ReactLoopAgent.cancel
     → dsh-agent-loop/lib/index.js:94                 ReactLoopInbox.clear
     → dsh-agent-loop/lib/index.js:85                 get nextStep
     → dsh-agent-loop/lib/index.js:175                current() → stateOf 得到 undefined
     → dsh-agent-loop/lib/index.js:177                ★ throw new Error(… "its projection registration is not active")

⑤ 升级成致命（顶层策略）
   dsh-app-boot/lib/index.js:3811  report(err, "fatal uncaught exception") → proc.exit(1)

抛点与读点原文

// dsh-agent-loop/lib/index.js:174-179
/** Read the current durable projection state. */
current() {
  const state = this.projections.stateOf(this.session, "inbox");
  if (state === void 0)
    throw new Error(`agent "${this.session.id}" cannot read inbox state: its projection registration is not active`);
  return state;
}

// dsh-agent-loop/lib/index.js:92-96
/** Durably cancel all pending input, clearing next-step before next-turn. */
clear() {
  this.splice("next-step", 0, this.nextStep.length, []);   // ← nextStep ⇒ current() ⇒ 上面那个 throw
  this.splice("next-turn", 0, this.nextTurn.length, []);
}

顶层处理器原文

// dsh-app-boot/lib/index.js:3802-3818
const report = (err, label) => {
  … 打印 "<label>" …
  if (release === void 0) { proc.exit(1); return; }
  (async () => { … await Promise.race([release(), timeout(FAIL_LOUD_RELEASE_TIMEOUT_MS)]); … })();
  proc.exit(1);                                   // ★ 无论如何都是 exit(1)
};
const onException = (err) => { report(err, "fatal uncaught exception"); };
proc.on("uncaughtException", onException);        // ★ 顶层注册

// dsh-agent-loop/lib/index.js:815-821
cancel(cause, options = {}) {
  if (!options.keepInbox) {          // ★ 逃生口：传 true 就跳过 clear()，也就不会读到已注销的投影
    this.inbox.clear();
    …
  }
  if (this.phase.kind !== "idle") this.phase.abort.abort(cause);
}

1. 逐字节相同的副本启动正常：把含该半截会话的 DSH_HOME 原样复制一份，实例照样启动并 3/3 打印启动 URL。
2. 崩溃后 2 秒就正常启动：某户 23:45:53 崩溃，23:45:55 就起来并打印了 URL。
3. 那批半截会话从未被 resume 过：产品文档说明 resume 会补写 interruptedTurnClosers，而它们的 closer 从未落盘；也没有任何进程持有它们的 fd/lock。
4. 半截是常态：子代理会话里 23–27% 本就是"末次 step 未闭合"的形态 ⇒ 半截不能当崩溃指纹。

上游（按推荐度）

1. ★ 最小可发布的一刀（1 行）：dsh-subagent-in-process-driver/lib/index.js:200 的 child.cancel({ kind: "parent" }) 改成 child.cancel({ kind: "parent" }, { keepInbox: true }) （或就地包 try/catch）。理由：逃生口已经存在且被其它调用点用过（见 §4.5）， 这一处漏传就是本 issue 的直接触发点；改完 clear() 根本不会被调用，throw 路径断掉， 且不影响语义（关停时本来就要丢弃 pending 输入）。
2. 让关停期清理幂等：ReactLoopInbox.current()（或 clear()）在投影未激活时 应返回空 state / no-op，而不是 throw。语义上「关停时读不到 pending 输入」的正确答案是「没有待处理输入」。
3. 调整 dispose 次序：保证 ReactLoopAgent.cancel() 在投影注销之前完成（或让 AbortSignal.onAbort 的订阅随同一 effect 一起注销，避免"拆完还回调"）。
4. 区分关停期与运行期异常：dsh-app-boot 的 onException 目前一律 proc.exit(1)；建议在关停阶段（已开始 dispose）把未捕获异常降级为**记录 + 继续收尾**， 并保留一个"关停期异常计数"以便观测。参考同仓 gateway.mjs 的 kept-alive 策略。
5. 回移主干重构：若 src-master 的 inbox.ts 确已去掉 throw 路径（见 §4.6）， 把它回移到 0.2.0 线即可同时覆盖 hasPending/locate 等其它读点 （稳定通道 0.1.5 上的同类崩溃就是从 hasPending 进的）。

我们侧（缓解，不冒充修法）

• 减少关停次数：这个 race 只在关停时发生 ⇒ 每少一次关停就少一次抽签。 本机的关停前置是 user-serve.sh 的 stop-cancel；健康检查自愈与升级会触发它。
• 让它在机读面可见：该异常目前只出现在 web.log，没有任何判定行/指标 ⇒ 需要一条巡检判据（含恢复侧，避免"告警只进不出"）。

# 1) 逐户 fatal 次数 + 它前一行（看是否紧跟 stop-cancel）
sudo -n -u infra sudo -n grep -nB1 'fatal uncaught exception' /home/<user>/.dsh-alpha/logs/web.log

# 2) 该户 stop-cancel 各 reason 次数（分母）
sudo -n -u infra sudo -n grep -oE 'stop-cancel ok=(yes|no)( reason=[a-z-]+)?' \
  /home/<user>/.dsh-alpha/logs/web.log | sort | uniq -c

# 3) 链条原件（逐行核对，别只看本页）
sudo -n -u infra sudo -n sed -n '174,179p;92,96p;85p;817p' \
  /opt/dsh/app-<version>/node_modules/@deepseek-ai/dsh-agent-loop/lib/index.js
sudo -n -u infra sudo -n sed -n '68,102p;127,131p' \
  /opt/dsh/app-<version>/node_modules/@deepseek-ai/dsh-session-projection/lib/index.js
sudo -n -u infra sudo -n sed -n '3802,3818p' \
  /opt/dsh/app-<version>/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js
sudo -n -u infra sudo -n sed -n '195,205p' \
  /opt/dsh/app-<version>/node_modules/@deepseek-ai/dsh-subagent-in-process-driver/lib/index.js

1. 没有受控复现：链条是静态逐行核出来的，没有拿到「同一进程内 disposer 先跑、abort 后跑」的运行时时序证据。
2. 日志栈恰好 10 帧 = Node 缺省 Error.stackTraceLimit ⇒ 无法从日志判定是哪一个 AbortController.abort() 触发的（处置链里的 agent 自有 abort、ownership teardown、profile-boot 的 shutdown 信号三者之一）。"是 dispose 链而非我们的 cancel RPC"是由判词语义（timeout vs cancel-unconfirmed）推出的，不是直接捕获。
3. report() 里 release === void 0 的早退分支（同样 exit(1)）没有逐行确认它在哪种装配下成立。
4. src-master 的 inbox 重构是取证席的静态读数，本页作者没有独立复核 master 源码；也可能主干另有取舍。
5. 「6 次 / 3 户」是本机 24 户、本日的现读；不等于全机队或历史总量。
6. 半截假设的证伪来自 36 席取证（含逐字节副本对照），不是本页作者逐件复核的。
7. 未验证：stable / master 通道是否同样受影响（同一份内核代码，理应一致，但没测）。