DSH Bug 反馈报告：工具执行崩溃后回合被标记为已结束，留下悬空 tool_calls，会话永久 400 卡死

[divaliu1408]

dsh-bug-report.md

[divaliu1408]

DSH Bug 反馈报告：工具执行崩溃后回合被标记为已结束，留下悬空 tool_calls，会话永久 400 卡死

复制本文件内容到 GitHub Issues 即可。标题建议用英文，正文中英文均可。

反馈渠道

• 仓库：https://github.com/deepseek-ai/deepseek-harness （npm 包 @deepseek-ai/dsh，代码在 apps/cli）
• 新建 Issue：https://github.com/deepseek-ai/deepseek-harness/issues/new
• 相关已有讨论（同族问题，可引用）：
  • Discussion #466：宿主被杀后会话日志留下未闭合 turn，冷启动无协调闭合，会话永久"运行中"
  • Discussion #161：tool calls 被丢弃（continuation deltas 带 null 时）

---

标题（Issue title）

Tool execution crash closes the turn without a tool/result, leaving a dangling
tool_calls block that makes every subsequent LLM request fail with 400
(session permanently stuck)

环境

• dsh 0.1.0-rc.6（npx 安装与 DSH Desktop 内置同版本）
• profile：web（dsh web）
• macOS（Apple Silicon），Node v24.15.0
• 模型：deepseek-v4-flash（deepseek-official）

现象

会话第 2 轮第一次 bash 调用执行时，harness 内部抛错：

Cannot read properties of undefined (reading 'prepare')

该轮以 turn/end reason=error 收尾，但已写入日志的 tool/call 从未得到对应的 tool/result。此后每一轮新消息都在调用 LLM 时失败：

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)

HTTP 400 INVALID_REQUEST（来自 DeepSeek API 对消息序列的校验），会话永久卡死，重发任何消息都无效。

根因分析

1. 工具执行崩溃路径只写了 step/end + turn/end(kind=error)，漏写了 tool/result。
2. 现有崩溃修复机制 interruptedTurnClosers（@deepseek-ai/dsh-session）只在日志以"未闭合 turn"结尾时触发；这里坏回合已被标记为 ended，日志看似平衡，修复永不触发。
3. 后续每轮请求都把这条悬空的 tool_calls 发给 API，被 400 拒绝，形成死锁。

日志证据

会话日志：~/.dsh/sessions/--Users-diva-Documents-dsh_test--/session-24316413-1b11-41b8-824c-ece67be21c52/session.jsonl.zstd
（zstd 解压后为 JSONL，关键事件序列如下，seq 连续）

第 2 轮：用户请求 → assistant 带 tool-call → 崩溃

seq 77158  user/message   "请你帮我展示一下，一共下载了几个插件。现在下载的这些插件都可以干什么。"
seq 77538  assistant/message  content 含 reasoning + text + tool-call
           tool-call id: call_00_dOpvpER1s5wEbP8wSnws9097, name: bash
seq 77539  tool/call     callId: call_00_dOpvpER1s5wEbP8wSnws9097, turn 2, step 1
seq 77540  step/end      {"turn":2,"step":1}
seq 77541  turn/end      {"turn":2,"reason":{"kind":"error","error":{"message":
           "Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}
           ← tool/result 从未出现

原始行（可直接粘贴到 issue）：

{"type":"assistant/message","seq":77538,"time":1786986863018,"data":{"turn":2,"step":1,"message":{"role":"assistant","content":[{"type":"reasoning","text":"The user asks: \"请你帮我展示一下，一共下载了几个插件。现在下载的这些插件都可以干什么。\" ..."},{"type":"text","text":"好的，我先核实一下当前 desktop profile 里实际安装的插件状态，再给你完整展示。"},{"type":"tool-call","id":"call_00_dOpvpER1s5wEbP8wSnws9097","name":"bash","arguments":"{\"command\": \"cd ~/.dsh/profiles/desktop\\necho \\\"=== dependencies（已安装的插件包）===\\\"\\npython3 -c ...\"}"}}]}}
{"type":"tool/call","seq":77539,"time":1786986863022,"data":{"turn":2,"step":1,"callId":"call_00_dOpvpER1s5wEbP8wSnws9097","name":"bash","arguments":"{\"command\": \"cd ~/.dsh/profiles/desktop\\necho ...\"}"}}
{"type":"step/end","seq":77540,"time":1786986863024,"data":{"turn":2,"step":1}}
{"type":"turn/end","seq":77541,"time":1786986863024,"data":{"turn":2,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}

第 3 轮起：每一轮都被 400 拒绝（此后 5 轮全部如此）

{"type":"assistant/chunk","seq":77547,"time":1786986927298,"data":{"turn":3,"step":1,"chunk":{"type":"finish","reason":{"kind":"error","failure":{"message":"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)","code":"INVALID_REQUEST","status":400}}}}}

建议修复

1. 工具执行出错路径：关闭 step/turn 前，先为已记录的 tool/call 合成一条 isError: true 的 tool/result（与 appendSkippedToolCall / interruptedTurnClosers 的现有做法一致）。
2. prepare/load 阶段兜底：扩展 interruptedTurnClosers 的触发条件——扫描整份日志，对"已闭合回合内悬空的 tool call"也做修复（当前它只处理日志以未闭合 turn 结尾的情况，见 @deepseek-ai/dsh-session/lib/index.js 的 interruptedTurnClosers）。
3. 请求构建兜底：序列化消息时若发现 tool_calls 无对应 tool 消息，合成错误结果或丢弃该调用，避免把非法序列发给 API。

临时规避（已验证可行）

把日志在孤儿 tool/call 处截断，让日志以"未闭合回合"结尾，触发 interruptedTurnClosers 自动补全 tool/result + step/end + turn/end(interrupted)，会话即可恢复。已用真实 harness 代码验证：截断后日志 seq 0..77539 连续，修复闭包 0..77542 连续，interruptedTurnClosers 恰好产出 3 条闭包事件。

附注

• 崩溃原始报错 Cannot read properties of undefined (reading 'prepare') 发生在工具执行路径（prepare 阶段），与本次卡死是同一事故的两面：既需要修崩溃本身，也需要修崩溃后的日志一致性。

[argszero]

Verified against rc.7 (99f6f02fec) — this is the cleanest report of a genuine repair gap I've seen, and it's a new mechanism in the session-corruption family. Your log evidence + truncation workaround + verified closure seqs make it unambiguous.

1. The repair gap confirmed at source. interruptedTurnClosers (packages/core/session/src/repair.ts:27+) tracks openTurn/openStep and pendingCalls, but:

• turn/end sets openTurn = null and clears pendingCalls (:36-39); step/end does the same (:46-49);
• the whole routine returns [] when openTurn === null at end-of-log (:60-62).
  So a crash that (a) committed tool/call, then (b) fired step/end + turn/end(reason=error) — leaving the call dangling inside a closed, balanced-looking turn — is invisible to repair. The log looks balanced; the dangling tool_calls block goes to the API every turn; 400 forever. This is distinct from the family's known mechanisms (which are all unbalanced/open-turn tails) — call it mechanism #9: balanced-but-dangling.

2. Your three fix suggestions map to real code paths:

• #1 (error path): the turn/end(reason=error) path (packages/core/agent-loop/src/agent.ts:306-318) fires in the finally without checking for outstanding tool/calls. appendSkippedToolCall (packages/core/agent-loop/src/tool-calls.ts:244-262) already exists for the abort path — the error path should use the same synthesis (or the turn-close should drain pendingCalls before writing turn/end).
• #2 (repair extension): interruptedTurnClosers could scan for dangling calls regardless of end-state — a tool/call whose callId never got a tool/result within the same turn, even when the turn is closed. This is the durable backstop (catches any writer that forgot, not just the current error path).
• #3 (serialize-time guard): serializeMessages (packages/llm/llm-deepseek/src/serialize.ts:105-140) maps tool_call_id verbatim with no pairing validation — a pre-send check that every tool_calls has a matching tool message would turn the permanent 400 into a one-turn visible error. This is the same "validate at the wire boundary" principle as the family's other fixes.

3. The crash itself is a separate bug worth its own thread. Cannot read properties of undefined (reading 'prepare') in the tool-execution path — the 400-deadlock is the consequence, but the cause (a tool executor missing its prepare context, likely a subprocess/sandbox setup failure) deserves isolation. If you have the stack trace, a second report focused on that crash would help the maintainers fix the trigger rather than just the symptom.

4. Family convergence. This is the 9th report in the session-corruption family (mechanisms across #1333/#1452/#1497/#1473/#1586/#2167/#2342/#2839 + now #2900), and the first with a balanced-looking log. The repair layer's "open turn only" trigger was the assumption that held until now — your report breaks it. The serialize-time pairing check (#3) is the one fix that protects all future writers, not just the current crash path.

5. Your truncation workaround is the correct recovery (truncate at the orphan tool/call → log ends unbalanced → interruptedTurnClosers fires → 3 closure events, verified 0..77542). Worth adding to dsh-doctor (moonquake2004's #1534) as an offline check: scan for closed turns with dangling tool/calls → truncate or synthesize.

Excellent report — the before/after seq evidence and the verified workaround make this actionable in one pass.

[divaliu1408]

---

感谢确认。修复缺口（#1/#2/#3）的代码路径对应完全正确，我也认同 #3（序列化时校验配对）是能保护所有未来写入方、而非只护住当前崩溃路径的兜底。截断恢复方案的表现与你描述完全一致（日志以未闭合回合结尾 → interruptedTurnClosers 触发 → 3 条闭包事件，seq 0..77542 连续）。

关于你要求单开线索的 "prepare" 崩溃：我这边没有运行时堆栈（桌面版不落盘 harness 日志），但我已经把触发条件隔离出来了——它不是子进程/沙箱初始化失败，而是工具调度器查找中的模块重复加载（dual-package hazard）。而这个崩溃正是"日志看似平衡、实则悬空"（balanced-but-dangling）的成因，也就是机制 #9 最常见的上游触发点。

崩溃点（唯一）。 agent-loop 的 startCall 读取 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)（packages/core/agent-loop/src/tool-calls.ts，runGroup 启动处）。TOOL_RUNTIME_SCHEDULER 是一个模块私有 Symbol（Symbol("@deepseek-ai/dsh-tools.scheduler")），ToolRuntime 以该 Symbol 为键、以类字段形式存放调度器。工具体从未执行——故障发生在调度器装配阶段，任何子进程/沙箱都还不存在（若是沙箱失败，会以 isError 的 tool/result 呈现，而不是派发前就把整个回合抛崩）。

为什么 Symbol 查不到。 本环境加载了三份 @deepseek-ai/dsh-tools，每份的 Symbol 身份都不同：

1. DSH Desktop 应用内置副本（rc.6）；
2. 桌面 profile 里被 pnpm 提升的副本 ~/.dsh/profiles/desktop/node_modules/@deepseek-ai/dsh-tools（rc.6）——因为已安装的 GitHub 插件（dsh-deepresearch、dsh-better-sidebar、dsh-memory-vault 等）把 @deepseek-ai/dsh-tools 声明成了普通依赖而被提升上来；
3. 扁平回退目录 $DSH_HOME/profiles/node_modules → 软链 → npx 安装副本（现为 rc.7）。

桌面的 installProfilePackageResolver 会把 loader 的每一个裸包导入都重定向为从 profile 目录解析。从 profile 目录解析时：@deepseek-ai/dsh-tools 命中副本 #2（profile 自带 node_modules 优先遮蔽），而 @deepseek-ai/dsh-agent-loop（profile 里没有）落到副本 #3。结果：tools 服务是由副本 #2 构造的 ToolRuntime（调度器挂在 #2 的 Symbol 下），agent-loop（来自副本 #3）却用 #3 的 Symbol 去取 → ctx.tools[symbol] 为 undefined → 报出 Cannot read properties of undefined (reading 'prepare')。

已验证： (a) 三份副本两两之间的 Symbol 身份测试全部为 false；(b) createRequire(profileDir).resolve('@deepseek-ai/dsh-tools') → profile 副本、…('@deepseek-ai/dsh-agent-loop') → npx 副本；(c) 会话日志显示任何工具（bash、skill 都是）在 tool/call 落库后立即回合报错、且为间歇性——同一个 skill 调用在 77 秒前的另一个会话里是成功的；(d) 间歇性与扁平回退的重新生成时机吻合：软链会指向"最后启动的那个 dsh 安装"（应用内置 vs npx CLI），且当前两者版本错位（rc.6 vs rc.7）。补充说明：原报告里 dsh web 那次崩溃早于我这次的埋点，且该会话日志已不存在，无法回溯验证当时的精确环境——但崩溃点是全工具执行路径中唯一读取 .prepare 的位置，且只要回退软链指向与运行中 harness 不同的安装，同样的双副本条件就必然存在。

建议修复（约一行，可根除整类问题）： 把调度器键改成 well-known symbol 或普通字符串键（例如 Symbol.for("@deepseek-ai/dsh-tools.scheduler")），让 agent-loop 与任意副本的 ToolRuntime 都能对齐；可选地，让双锚点解析遵守其文档契约（"bundle 名优先从 dsh 安装解析"）——目前 profile 里被提升的核心包会在扁平回退被查询之前遮蔽安装副本。

用户侧临时规避（也是干净的复现对照）：删掉 profile node_modules 里被提升的核心 @deepseek-ai/* 包，解析会一致地落到扁平回退，崩溃即消失。

---

附：三份副本的来源（本机排查补充）

排查中发现本机存在三份 @deepseek-ai/dsh-tools（含其他核心包），版本错位（rc.6 / rc.6 / rc.7）。三份副本分别从何而来：

① 应用内置  rc.6
   来源：DSH Desktop 是 Electron 应用，打包时把整个 harness 及全部依赖
         （@deepseek-ai/dsh、dsh-tools、cordis…）都塞进了
         app.asar.unpacked/node_modules —— 设计内行为，应用自包含，不依赖系统。

② profile pnpm 提升  rc.6   ← 意外副本（崩溃元凶）
   来源：用 `dsh plugin --profile desktop add <插件>` 安装的 GitHub 插件
         （dsh-deepresearch、dsh-better-sidebar、dsh-memory-vault、dsh-web-search-pro…）
         把 @deepseek-ai/dsh-tools、@deepseek-ai/cordis、@deepseek-ai/dsh-settings 等
         **核心包声明成了普通 dependencies**（而不是 peerDependencies），
         pnpm（nodeLinker: hoisted）安装时就"顺手"把它们提升进
         profile 顶层的 node_modules —— 在 pnpm-lock.yaml 里能看到
         `'@deepseek-ai/dsh-tools': ^0.1.0-rc.6` 挂在那些插件名下。

③ npx 缓存  rc.7
   来源：在终端跑过 `npx @deepseek-ai/dsh`（bug report 就是 npx `dsh web`
         会话里崩的），npx 把包缓存到 ~/.npm/_npx/<hash>/（version ^0.1.0-rc.7）。
         而 ~/.dsh/profiles/node_modules 是 dsh 自己维护的"扁平回退"目录：
         每次 harness 启动时，把 app manifest 的依赖闭包逐一做成软链，
         指向"最后一次启动的那个 dsh 安装"——上次跑的是 npx（rc.7）就指 npx，
         之后桌面应用重启又改指回应用内置（rc.6）。

严格说：只有 ② 是"不该存在的副本"（已清理）；① 和 ③ 是两条合法但互不知道对方的安装渠道，而 dsh 的回退软链机制把它们串在了一起，碰撞出这个 bug。根治方向：第三方插件把 @deepseek-ai/* 改为 peerDependencies，或让回退软链固定指向应用内置。