工具调用失败留下悬挂 tool_calls,会话被 400 INVALID_REQUEST 永久卡死

[snow-The]

工具调用失败(调度器缺失)会在会话历史留下悬挂的 tool_calls,之后该会话永久卡死,每个请求都被模型 API 以 400 拒绝,且没有任何自动恢复手段。

复现、预期与验收

• 复现步骤：
  1. 在 web profile 里安装一个把 @deepseek-ai/dsh-tools 带进 profile 依赖图的插件(如 @snow-the/dsh-busyloop@0.1.6 曾把 dsh-tools 声明为运行时依赖),或任何导致 profile node_modules 重链后立即重启的操作。
  2. 重启 dsh web,在旧会话(或新会话)里让 agent 发起第一次工具调用。
  3. 观察：tool/call 事件落盘后,工具执行抛 Cannot read properties of undefined (reading 'prepare'),没有 tool/result 事件;turn 以 error 结束。
  4. 之后该会话的每一个请求都被 API 拒绝：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)(INVALID_REQUEST,400)——会话永久卡死,无法继续。
• 实际结果：一次调度器层的工具执行失败,把整个会话历史永久污染;用户被迫放弃该会话。
• 预期结果：工具执行失败时,agent-loop 应合成一条错误 tool/result(如 isError 消息)落盘,保证"assistant 的 tool_calls 后面必有 tool messages"这一 API 不变量;会话应能继续。
• 环境：Windows 11, dsh @deepseek-ai/dsh@0.1.1-rc.2(npm 全局),web profile。
• 验收条件：模拟调度器缺失(或任何 startCall 阶段的异常)后,会话历史中每个 assistant tool_calls 消息都有对应的 tool messages;会话不因一次工具执行失败而卡死。

根因定位(附带证据)

崩溃发生在 dsh-agent-loop 的工具调度路径：

// dsh-agent-loop/lib/index.js:193 (startCall)
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);

TOOL_RUNTIME_SCHEDULER 是 @deepseek-ai/dsh-tools 导出的 Symbol。当 ctx.tools 实例来自另一个 dsh-tools 模块实例(例如 profile 安装重链窗口期产生的第二个模块实例)时,ctx.tools[symbol] 为 undefined,此处直接抛 Cannot read properties of undefined (reading 'prepare'),而 appendToolCall 已经先一步把 assistant 的 tool_calls 写进了会话事件流(tool/call 事件已落盘),错误路径没有补写 tool/result。

会话文件中的事件序列(实测)：

assistant/message  (含 tool-call)
tool/call          (appendToolCall 成功落盘)
step/end           ← error: Cannot read properties of undefined (reading 'prepare')
turn/end           ← kind: error
… 之后每个 turn：
request/header → assistant/chunk(finish error)
  "An assistant message with 'tool_calls' must be followed by tool messages …" (INVALID_REQUEST 400)

建议修复

在 startCall/调度路径上对 ctx.tools[TOOL_RUNTIME_SCHEDULER] 缺失或 prepare 抛错的情况兜底：为每个已落盘 tool/call 的调用补写一条错误 tool/result(isError=true),再让 step 失败——保证历史满足"tool_calls 必须紧跟 tool messages"的 API 不变量,避免单次工具执行失败毒化整个会话。

（附带发现:profile 安装插件后立即重启存在 dsh-tools 模块实例分裂的窗口期,建议 boot 时校验工具调度器完整性并给出明确报错,而不是让首个工具调用裸崩。触发本次问题的插件侧已修复为不把宿主包声明为运行时依赖,但宿主对"工具执行失败 → 会话永久卡死"的脆弱性仍然存在。）

[yamingmou]

Hi @snow-The,

We investigated your report in depth and confirmed the behavior you described — prepare() throwing synchronously when the scheduler symbol is undefined leaves a dangling tool/call with no tool/result, permanently poisoning the session.

Our analysis found two additional things that may be relevant:

1. Two more entry points lead to the same dangling state through the same outer catch path — dispatch rejection (:197) and finalize/finish failure (:181 inside commitReady). All three entries share the same recovery gap.
2. The engine already owns the exact fix — appendSkippedToolCall (:274-290) synthesizes an isError: true result on the abort path, applied at two layers (:258, :139). The failure path bypasses it entirely. The code's own JSDoc (:159-160) documents this asymmetry: "Scheduler failure drains dispatches without committing synthetic recovery results."

We filed a separate report covering the full failure surface, detailed evidence chain, and fix proposals reusing appendSkippedToolCall on the failure catch path: #4549 — that's where we left our deeper notes.

---

我们深入调查了你的报告，确认了你描述的行为——prepare() 在 scheduler symbol 为 undefined 时同步抛错，留下悬挂的 tool/call（无 tool/result），会话被永久污染。

我们的分析发现了两个可能相关的新发现：

1. 另有两个入口也会导致同样的悬挂状态，且都走同一条外层 catch 路径——dispatch 拒绝（:197）和 finalize/finish 失败（:181，commitReady 内部）。三个入口共享同一个恢复缺口。
2. 引擎已有现成的修复机制——appendSkippedToolCall（:274-290）在 abort 路径上合成 isError: true 结果，且在两层上都应用了（:258、:139）。failure 路径完全绕开了它。代码自己的 JSDoc（:159-160）就记录了这种不对称："Scheduler failure drains dispatches without committing synthetic recovery results."

相关问题、详细证据链及修复方案见我们的独立报告：#4549（我们更多的笔记都在那）。