[Bug] claimed 的输入在 prepareRequest 抛错时会永久丢失：本机 154 份存档里 14 例

[mengge237]

先钉版本：我本机装的是 @deepseek-ai/dsh 0.1.5-rc.1，跑起来的内部包是 0.1.5-rc.2（dsh-agent-loop / dsh-api-session-controller / dsh-client-ui-chat），Windows 11，web profile。每条都给两处行号：我本机安装目录里的编译产物（0.1.5-rc.2），和 2026-09-17 的 master 源码。行号会漂，标识名和事件形状为准。

一句话

我在一轮里发的消息，会先进 pending inbox，等下一个 step 边界被 claim；而它被写成 durable user/message 的那一次 append，排在 step() 里 prepareRequest() 之后。于是 prepareRequest 一抛错，这条消息就既不在 inbox、也不在日志里 —— 我在自己的 154 份会话存档里量到 14 例，合计 6379 字符，最长一条 5746。

事件形状（脱敏，取自那 14 例之一）

agent/inbox/spliced  {target:"next-turn", start:0, inserted:[<msg>]}   <- 接受
turn/start           {turn:N}
agent/inbox/spliced  {target:"next-turn", start:0, removedCount:1}      <- claim：只动投影，不写 user/message
turn/end             {reason:{kind:"error", error:{code:"UNKNOWN", ...}}}
（到此为止：这份存档里没有这条消息的 user/message，也没有别的位置收留它。）

代码位置

1. 窗口本身。 master packages/core/agent-loop/src/agent.ts：:245 在 pre-step 里 this.inbox.claim(target, position.turn)；那条 user/message 直到 :376 才 this.session.append('user/message', …)，中间隔着 :361 的 await this.prepareRequest(turn, step, signal)。claim 自己只写一条 agent/inbox/spliced（master packages/core/agent-loop/src/inbox.ts:109-113），不写那条 user/message。本机 0.1.5-rc.2 对应 dsh-agent-loop/lib/index.js:104-107 与 :1028。
2. prepareRequest 会抛什么。 master 的 prepareRequest 里有三处：agent/request waterfall 抛的、if (!proposedConfig.provider || !proposedConfig.model) 那条守卫、以及 await this.loopCtx.llm.prepareCall(proposedConfig, signal)。后者在本机是 dsh-llm-pi-ai/lib/index.js:1824 的 prepareCall → modelInfo → modelOf，会抛两类配置类错误：模型不在目录里时 UNKNOWN_MODEL（:1779）、profile 记了 modelErrors/catalog 失败时 INVALID_CONFIG（:1776）。顺带一句：同一段代码把 NO_ADAPTER 显式吞掉继续走（catch (error) { if (… code !== 'NO_ADAPTER') throw error; … }），所以它不是这条路径的入口；UNKNOWN_MODEL / INVALID_CONFIG 是。
3. 同类：cancel 会把整队摘掉。 master agent.ts:151 / 0.1.5-rc.2 lib/index.js:799：keepInbox 不为真时 inbox.clear()。宿主侧 Stop 带的是 keepInbox: true，但 disposal 那条路（0.1.5-rc.2 lib/index.js:1656 的 cancel({ kind: 'disposed' })）没带。我这边另有 12 例 outcome:"canceled" 之后再没出现过的输入。

实测

• 面：$DATA_HOME/sessions/<workspace>/<session>/session*.jsonl.zstd，我扫了 154 份（扫描时点 2026-09-17）。
• 口径：解帧后按 agent/inbox/spliced 折叠出 inbox 投影，跟 durable user/message 的 id 集合比对（必须先扫全档再折叠，否则那些随后就被正常 append 的条目会被误判）。
• 14 例被 claim 之后再没出现（2026-09-04/05；字符数 5746 / 521 / 44 / 14 / 14 / 11 / 7 / 7 / 6 / 2 / 2 / 2 / 2 / 1），12 例 outcome:"canceled" 之后再没出现。
• 909 条消息「先进 inbox 再落盘」的延迟：p50 61 ms、p90 41.8 s、>5 min 55 条、最长 5.6 小时。
• 扫描脚本十几行、只读，需要我贴出来。

复现

不需要任何特别的内容或端点，任选一个让 prepareRequest 抛错的入口即可：

1. 把某个会话钉到一个 provider 目录里不存在的模型 id（或被改成畸形、profile 报 INVALID_CONFIG 的条目）；
2. 在这个会话里开一轮、发一条消息；
3. 存档里就是上面的形状：turn/end 判 UNKNOWN_MODEL（或 INVALID_CONFIG），而这条消息的 user/message 永远不出现。

说明一句我在自己机器上的诚实边界：那 14 例的现场是同一个 prepareRequest 里另一个抛错（我当时一份畸形的模型条目，Cannot read properties of undefined (reading 'length')），UNKNOWN_MODEL 这条入口我是读调用链确认的，没有为它单独构造现场 —— 那要动正在跑的宿主的模型配置。

建议（按成本排）

1. claim 与落盘之间别夹可抛错的调用：要么先 append durable 再消费 inbox，要么在 catch 里把 claimed 的消息放回去。现在这一步失败，我打进去的字就没了，日志里连痕迹都没有。
2. inbox.clear() 别静默：cancel/disposal 摘掉了哪些消息，至少留一条记录，产品事后才有机会告诉我「那句话没发出去」。

这些是我给自己做会话体检、解存档数事件的时候量出来的；跟模型、provider 和对话内容都无关。

[argszero]

Thanks for the measurement — 14 out of 154 archived sessions is a much clearer signal than a hand-made repro, and the window you identified is exactly right.

I read the claim path and both halves of a repair turn out to be public API, so this can be closed from outside the tree without an upstream change:

• Observe — agent/inbox/claimed is a declared agent-scoped event (packages/core/agent/src/runtime-types.ts:296, payload { agent, message, turn }), emitted by ReactLoopInbox.claim at agent-loop/src/inbox.ts:114. Its listener is untagged, and scopeTarget admits untagged listeners globally, so a plugin mounted anywhere sees every claim.
• Recover — Agent.send(message, target, wakeup) is public. send(message, target, false) is precisely "append to that pending list"; true additionally wakes the driver.

So the message does not have to be merely reported. Starting from the claim event, the guard waits for the turn to close, proves the input never became durable, and puts the same message object back.

I have published that as a plugin:

@argszero/cordis-plugin-inbox-claim-guard@0.1.0

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-inbox-claim-guard
• source: https://github.com/argszero/cordis-plugin-inbox-claim-guard

npm install @argszero/cordis-plugin-inbox-claim-guard

- insert:
    - id: inbox-claim-guard
      name: '@argszero/cordis-plugin-inbox-claim-guard'
      config:
        mode: restore           # restore | report | off
        wakeup: true            # may a restored message wake the driver
        maxWakesPerMessage: 2   # wake budget per message id
        restoreOnAbort: false   # cancel() drops pending input on purpose

Three details that decided the implementation, in case they are useful for the core fix:

1. Not every closed claim is a loss. A blocked turn is a rejected step: the claimed event's own contract says a rejected step leaves the message "neither discarded nor re-emitted as a user/message". That is deliberate consumption, and repairing it would resurrect work something explicitly declined. Only error is a loss; aborted is opt-in because cancel() clears pending input on purpose. The proof of durability is user/message on the global session/event seam — event.data is the message (core/session/src/types.ts:297), so its id is the identity that was claimed.

2. The boundary is recoverable, so it does not have to be guessed. A claimed batch is [...nextStep, ...nextTurn.slice(0, 1)], and a blind restore would have to decide which list each message came from. It does not have to: claim removes through mutate(..., discardRemoved: false), which is the only inbox mutation that removes without inserting and emits neither outcome: 'canceled' nor an agent/inbox/discarded event — every public mutation (clear / remove / replace / splice) uses discardRemoved: true and carries outcome: 'canceled'. The agent/inbox/spliced events that immediately precede a claim therefore name the exact target list, in claim order. Where that discriminator is absent the guard degrades to message.source.kind (user → next-turn, anything else → next-step) rather than guessing wrong.

3. Restore at the idle transition, not at turn/end. At turn/end the failed turn is still running, where wakeDriver refuses to latch a wake that cannot join the aborted activity (agent-loop/src/agent.ts:187-196), and the error path rethrows before the loop bottom that would claim it (:322-343). Restoring on the idle transition (emitted by kick's finally) gets the message back and lets the wake actually re-drive a turn instead of leaving it parked. A repeatedly failing input exhausts maxWakesPerMessage and is then restored parked — visible as pending input, not looping.

Two things I deliberately did not do, to avoid buying durability by changing the log:

• I did not append user/message early from agent/pre-step and return an empty batch. That would move the durable user message before the system/message the core appends after prepareRequest, i.e. it would reorder the log rather than protect it. Prevention is still core's call; the append-before-prepareRequest ordering question is a real design decision, not a patch.
• The guard restores the message, not the step's side effects, and it cannot stop a repeated failure — only keep the input from vanishing. If the underlying throw is a request extension that fails on every request, you will see the loss detected, repaired, and then detected again up to the wake budget.

Version note: the exact boundary directory above (the spliced outcome discriminator) does not exist before 0.1.5, so the plugin's peer range starts at 0.1.5-alpha.1. On older releases it still works, via the source.kind fallback.

[mengge237]

装的那版（dsh 0.1.5-rc.1，产物 0.1.5-rc.2）我逐条对过了：claim 与 agent/inbox/claimed 在 dsh-agent-loop/lib/index.js:104-107，outcome 和 agent/inbox/discarded 的分岔在 :197 :207（claim 两次都传 false，splice() 走 :161 的 true），窗口是 :889 → :1017 → :1028。你 README 里那句 npm test 我也跑了：clone 装依赖后 19 条全过，node v24.12，解析到的正是我这条线（dsh-agent 0.1.5-rc.2 / cordis 4.0.2）。

两处要补，都是我的问题。正文里「日志里连痕迹都没有」说过头了 —— claim 写了 agent/inbox/spliced，只是里面只有 {target, start, removedCount, inserted: []}，没有正文。能比对的只有计数，这恰好是你那个 outcome === undefined 判别式站得住的原因。另一条：丢输入只可能发生在第一次 prepareRequest，:1016 的 while (true) 里，:1028 的 append 挂着 if (firstAttempt)，重试轮再抛时输入已经在档了。

还没装。装要重启宿主，本机有别的会话在跑；而且 peer 只钉了 cordis，版本表全在 README 里，装错线 npm 不会响 —— 你把 @deepseek-ai/dsh-agent（连 dsh-session）写进 peerDependencies，我就直接装。还有一格想问清楚：我那 12 例 canceled-lost 走的是 :1656 disposal 不带 keepInbox 的 clear()，按 restoreOnAbort: false 不修；可那种 turn 若关成 error 而不是 aborted，恢复就落进一个正在 dispose 的 agent，而你的 disposed 已经删了那份 state。这句是我读代码推的，没跑过 —— 你定它该落哪侧，我照着配。

[mengge237]

同补版本口径：壳 0.1.5-rc.1 只是 CLI 层，运行时是 0.1.5-rc.2（= npm latest，09-10 就发了），行号请按 rc.2 产物看；
升壳到 rc.2 是 49 KB 的事、行为零变化，所以 @latest 复现与这台一致。argszero 那条 guard 也是解析到 rc.2 这条线跑的。

[mengge237]

把落点收到最小一格；另一个更大的问题（事前余额检查）另说，不混在这条里。

真正会丢内容的只有一处：第一次 prepareRequest。firstAttempt 同时管着「是否 append 那条 durable user/message」，而 append 在它之后 —— 抛错时消息已被 claim、又没落档。0.1.7-rc.1 的产物上仍可复算：append 那行仍挂在 if (firstAttempt) 上，claim 在 pre-step。（keepInbox 那半我 09-18 已更正过：clear() 走 mutate(…, discardRemoved:true)，日志侧有 agent/inbox/spliced 与 discarded，缺的是正文本身和「让用户知道这句话没发出去」。）

最小落地：只给第一次 attempt 加一条回滚 —— 抛错时把已 claim 的消息放回 inbox（keepInbox 语义已经在那儿了，成功路径一行不改）。不重排 claim/append 的先后，也不新增并发面。

稳定复现口（与内容和 provider 无关）：把会话模型钉成一个不存在的 id → 第一次 prepareRequest 必抛 UNKNOWN_MODEL → 那句已经发出去的输入既没进存档，也没有任何「这句话没发出去」的提示。本机 154 份存档量到 14 例（合计 6,379 字、最长 5,746），其中 12 例在 canceled 之后再没出现过。

判据（盯代码，不用等回音）：

grep -n "firstAttempt" node_modules/@deepseek-ai/dsh-agent-loop/lib/index.js | head

改完之后，那行 durable append 不该再由 firstAttempt 单独把关；或者抛错分支里能读到一次 inbox 回滚。