工具分发抛错后未补合成 tool/result，会话被永久毒死且无恢复路径

[james4787]

Summary

tool/call 一旦落盘，若其后的调度 prepare 抛错，该调用永远不会得到 tool/result。
此后该会话的每次请求都会因 provider 侧配对校验失败而报
DeepSeek Messages tool calls need immediate results（INVALID_REQUEST），会话永久不可用。

Reproduction

制造任意一次工具分发失败（例如 resolutionMode 那个 issue 引起的失败），然后向同一会话继续发言。

代码路径：packages/core/agent-loop/src/tool-calls.ts 的 startCall 中，

callSeqs[index] = appendToolCall(session, turn, step, call.block)              // 先落 tool/call
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)    // 在此抛出

异常冒泡至外层 catch 后被 rethrow。该 call 既没有结果，也未进入 inFlight，
因此 commitReady() 同样不会补。

Current behavior

turn/end { kind: 'error', error: { message: 'DeepSeek Messages tool calls need immediate results', code: 'INVALID_REQUEST' } }

每次发言都如此。packages/core/session/src/repair.ts 不会介入：它以 openTurn === null
判定日志 balanced 并直接 return []（注释 "Balanced log (no crash mid-turn): nothing to close"），
而此处 turn 已正常结束（turn/end 已写入）。也没有任何 CLI 或产品内恢复路径，用户只能放弃该会话。

会话日志形态（实测）：

assistant/message  content=[reasoning, tool-call(id=X)]
tool/call          callId=X
step/end
turn/end           { kind: 'error', ... }

Expected behavior

分发 prepare 抛出时，应为已记录的 tool/call 追加一条错误 tool/result
（可直接复用 repair.ts 已有的合成结果形状与 TOOL_OUTCOME_UNKNOWN），使 transcript 始终
provider-valid。repair.ts 也宜覆盖「turn 已结束但仍有未配对调用」的情形。

Environment

• upstream/master ddefc45fbc（0.1.6-alpha.2）
• macOS 15 (darwin 23.6.0)，Node v26.3.0

补充：本地已按 repair.ts 的格式手工补合成结果恢复该会话——只需追加一条 surfaceOp: 'append'
的 tool/result；serialize 会合并连续的 user 消息并把 tool_result 重排到前，正好清掉 pending。

[ScourgeStorm1]

深有同感！我们今天排查 #7128 时，由于工具调度器在 .prepare 处抛出，会话同样被记录了 6 个无结果的悬空 tool-call，导致随后发起的每一次对话都报：

LlmError: DeepSeek Messages tool calls need immediate results (code: INVALID_REQUEST)

完全同意楼主对于 interruptedTurnClosers 的分析——因外层捕获异常后写入了 turn/end (error)，日志在形式上已被关闭，现有恢复逻辑判定其为 balanced 直接返回空数组，彻底失去了补齐合成结果的机会。

关于受损会话（v3 jsonl.zstd）的抢救方案验证：
我们对包含 22 轮对话、800+ 事件的真实故障会话执行了离线无损抢救与验证：

1. 保留平衡前缀：前 10 轮所有已闭合且配对的 739 个事件保持不可变；
2. 重构悬空尾部：将崩溃轮次中因调度异常而中断的 assistant/message 内部的 tool-call 块转义为说明文本（保留助手的全部 reasoning 思维链文本和用户原话，不伪造成功结果）；
3. 序列密集重编号：对全局事件 seq 执行密集重编号（0..N-1），并同步重映射 sourceEventSeqs 与 surfaceOp: replace 区间；
4. 标准两帧压缩：首帧独立承载 header，次帧打包全量 event records。

修复后调用 @deepseek-ai/dsh-llm-deepseek 的编译版 serialize() 进行完整 Surface 校验：234 条 wire 消息、116 组工具调用与结果 1:1 闭合，配对校验通过，会话已完全恢复正常交互。

强烈支持楼主的建议：
期望官方能在 repair.ts 或回放加载阶段（如 prepare()）主动检测闭合回合中悬空的 tool/call，自动按 TOOL_OUTCOME_UNKNOWN 追加合成错误结果（isError: true），避免一次偶发的工具调度异常演变成会话级别的“永久脑死亡”。

[argszero]

Thanks — your two-line window is exactly right (tool-calls.ts: appendToolCall at :168, then await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...) at :170), and both of you reproduce on 0.1.6-alpha.2. Two additions to the analysis, one correction about where the fix belongs, and one thing a plugin can do today.

The failing site has a sibling that already does the right thing

Twenty lines below your path, runGroup's abort branch writes an ordered synthetic result for every call it never started (appendSkippedToolCall, :241 / :250). The catch at :232 does not: it parks the error in schedulerFailure, drains in-flight dispatches, and rethrows — the function's own docstring states the policy ("Scheduler failure drains dispatches without committing synthetic recovery results").

So the helper and the machinery already exist one branch away, and at the moment prepare throws the step is still open — step/end / turn/end are appended only after the failure has propagated out of runGroup. The fix is consequently small and local: in startCall's failure path (or in that catch), for every index in [committed, started) that has a callSeqs[index], append a TOOL_OUTCOME_UNKNOWN-shaped error result citing that seq before rethrowing. Both boundary events then close over a log whose declared calls are all answered.

repair.ts is the wrong home for it

Its premise is "the process died mid-turn". It scans for an open turn and returns [] the moment openTurn === null — repair.ts:82, "Balanced log (no crash mid-turn): nothing to close" — and its trace clears pendingCalls at step/end (:50-51). The log you posted closes normally (step/end, then turn/end { kind: 'error' }), so it is balanced by that definition and always will be. Teaching it your shape is not a patch but a redefinition: from "close an interrupted tail" to "report a turn that closed while a call it declared was never answered".

For the same reason a post-hoc writer cannot do it from inside the product. A tool/result appended after the turn is closed has no open step to name and no pending call in it, and the package-owned session invariant requires both (packages/core/session/src/invariant.ts:136 and :139 — requireOpenStep(...) plus trace.pendingCalls.has(callId)); the one escape hatch, TOOL_NOT_STARTED, asserts the opposite of what this log shows. Appending it anyway writes an event that contradicts the relation the log declares. That is reserved for an interrupted tail, which is exactly why the shutdown path yours mirrors here does not cover a turn that failed and closed.

A plugin that repairs the request instead of the log

I published @argszero/cordis-plugin-orphan-tool-call-guard@0.1.0 — it does not touch the log at all; it makes the poisoned session talk to a provider again:

npm install @argszero/cordis-plugin-orphan-tool-call-guard
# or mount the row from its cordis.patch.yml:
#   - insert: [ { id: orphan-tool-call-guard, name: '@argszero/cordis-plugin-orphan-tool-call-guard' } ]

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-orphan-tool-call-guard
• source: https://github.com/argszero/cordis-plugin-orphan-tool-call-guard

It listens on the documented llm/stream waterfall, finds every tool-call block no tool-result answers, and inserts one synthetic result per orphan directly after the assistant message that declared it — the exact message and wording repair.ts uses (role: 'user', source.kind: 'tool', isError: true, TOOL_OUTCOME_UNKNOWN text). The repair is re-derived on each later request, so the session stays usable; the durable log keeps the orphan and keeps telling the truth. mode: observe reports without repairing, and maxRepairs (default 64) is an all-or-nothing breaker.

Verification: the tests mount the real @deepseek-ai/cordis context, the real @deepseek-ai/dsh-llm service and its real llm/stream waterfall; the only stand-in is the provider backend, and it enforces the rule that a dangling tool_calls block is refused. The unmounted control reproduces your INVALID_REQUEST; the synthetic message is asserted against interruptedTurnClosers() rather than against a copy of its wording; the repaired stream is run through the shipped @deepseek-ai/dsh-llm/invariant. The packed tarball was then installed into clean projects and probed on 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.2 and 0.1.6-alpha.2 — 4/4 checks each, from the published artifact rather than the working tree.

Its honest limits, since they matter when choosing between this and a hand repair:

• It fixes the request, not the log. The orphan stays in the session; every future request carries one synthetic message the log does not have.
• A request assembled by dsh-agent-loop is marked by object identity, and the agent-loop's reconstruction invariant only validates marked requests. The replacement this plugin dispatches is a different object — it is not passed off as the loop's log-derived transcript, and it is not equal to session.deriveMessages() by construction. That is the trade.
• Listeners earlier in the llm/stream waterfall see two dispatches for a repaired request (the original, which reaches no provider, and the replacement). Inherent to replacing a request at a waterfall whose next() takes no arguments.

To @ScourgeStorm1 — it is not a fabricated success

The synthetic result is isError: true and says, verbatim, what the shipped crash path says: "…no result was durably recorded. Its outcome is unknown. Decide whether to retry from the tool semantics: retry only if the operation is read-only or idempotent; if it may have side effects, first verify external state or ask the user. Do not retry blindly." It asserts no success and no failure. It answers your 6 dangling calls in one pass.

Both of your rescues — an offline append, or escaping the tool-call blocks into explanatory text and renumbering — are rewrites of the artifact, and they are the durable route; the harness will not do it for you until the writer-side fix above lands. The plugin exists for the sessions nobody wants to hand-edit, and for the case where the session files are not yours to edit.