[Bug] 工具执行崩溃后会话留下悬空 tool_call，后续所有回合报 400 insufficient tool messages following tool_calls message

[ace495903289-code]

现象

Web GUI 中某个会话一旦在工具执行阶段崩溃，该会话从此所有后续请求（包括点"继续"）都会失败，报错：

An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)

环境

• @deepseek-ai/dsh 0.1.0-rc.6（npm 本地安装，Windows 11，Node 22.22）
• 会话持久化：JSONL + zstd 多帧（~/.dsh/sessions/）

根因（已解包会话日志取证）

对会话日志（逐行 zstd 帧的 jsonl）分析后确认事件序列：

1. 工具执行时内部抛错：Cannot read properties of undefined (reading 'prepare')（grep、pwsh 均触发过），turn 以 reason: error 结束；
2. 崩溃时没有写入对应的 tool/result 记录——日志里 32 条 tool/call 只有 31 条 tool/result，留下悬空 tool_call（call_00_xxx）；
3. 此后该会话历史中始终存在一条带 tool_calls 却无对应 tool 结果的消息，每次请求发给 DeepSeek API 都被严格校验拒绝 → 恒 400，会话永久无法恢复。

复现步骤

1. 让 agent 执行工具调用（如 pwsh / grep）；
2. 在工具执行阶段触发内部崩溃（本环境为服务重启后恢复会话时较易触发）；
3. 之后用户任何"继续/重新生成"操作都会复现 400，且新回合仍持续失败。

建议

1. 工具执行抛错时，应兜底写入一条 isError 的 tool/result（而不是直接结束 turn 不落盘），保证 assistant tool_calls 消息总有对应的 tool 消息；
2. Cannot read properties of undefined (reading 'prepare') 本身也应修复——疑似服务重启/热重载后工具运行时的 prepare 未初始化；
3. 对历史中已存在的悬空 tool_call，加载时建议做兼容修复（补合成 tool 结果），避免整个会话报废。

[boyin111-1]

Source-level confirmation + offline-detection note (English)

Your forensics are exact, and this is offline-detectable. It is the same
failure family as #1363 (a tool_calls assistant message with no responding
tool message → permanent 400 on every resumption), with the added twist here
of an internal crash (Cannot read properties of undefined (reading 'prepare'))
skipping the tool/result write entirely.

The durable signal is the session log, so a static scan can catch it before any
model request:

• tool/call events carry callId (packages/core/session/src/types.ts:279);
• tool/result events carry the matching id in message.source.callId
  (types.ts:291; ToolResultMessage.callId at packages/core/tools/src/index.ts:315).
• An orphan = a callId whose count in tool/call exceeds its matches in
  tool/result and whose turn already produced results. Your "32 tool/call
  vs 31 tool/result" observation is precisely this.

I paired this against the real session-event schema and added it as an offline
--session scan to the dsh-doctor community tool (available now, no install).

npx --yes github:boyin111-1/dsh-doctor        # profile + manifest checks
npx --yes github:boyin111-1/dsh-doctor --session <your session.jsonl.zstd>

It reports a hard error for an orphaned call in a completed turn (the
"every future request 400s" case), and a warning (not an error) for a dangling
call in the latest still-active turn, so scanning a live session doesn't
false-positive. Your three proposed fixes are all sensible; point #2 (the
prepare-undefined crash) is the actual trigger and is worth isolating
independently since it also aborts the tool/result write. No fix/release
timing implied.