[Bug] Scheduler failure leaves dangling tool/call — session permanently returns 400 INVALID_REQUEST (fix: reuse appendSkippedToolCall, #4017 follow-up)

[yamingmou]

Summary

When a tool call fails through any of three failure paths (prepare throws / dispatch rejects / finalize throws), tool/call is already appended but no tool/result is ever written. The session becomes permanently unusable — every subsequent request is rejected by the model API with INVALID_REQUEST (400).

The engine already owns the recovery logic (appendSkippedToolCall at dsh-agent-loop/lib/index.js:274-290) and applies it on the abort path. But the failure path bypasses it entirely — the outer catch (:252-255) only drains dispatches and rethrows, never writing recovery. The code's own JSDoc (:159-160) documents this asymmetry: "Scheduler failure drains dispatches without committing synthetic recovery results."

Suggested fix: Apply appendSkippedToolCall in the failure catch path — reuse existing machinery, no new code paths needed.

Trigger Condition

1. A tool call enters the scheduler
2. Any of: prepare throws / dispatch rejects / finalize throws
3. tool/call is already durable, tool/result is never written
4. Session is permanently poisoned — no automatic recovery

Minimal Repro

// 1. Configure a tool where ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined
//    (e.g., split module instance, or a tool not registered for the profile)
// 2. Invoke the tool — prepare() throws synchronously at :193
// 3. Observe: session history now contains tool/call with no tool/result
// 4. Send any subsequent message → model API returns 400 INVALID_REQUEST
// 5. Session is permanently unusable; no recovery without manual intervention

Related

• [#4017](工具调用失败留下悬挂 tool_calls,会话被 400 INVALID_REQUEST 永久卡死 #4017) reported entry point 1 (prepare throws). This report adds entry points 2-3 and identifies the asymmetric recovery design as the root cause. Not a duplicate — extends 工具调用失败留下悬挂 tool_calls,会话被 400 INVALID_REQUEST 永久卡死 #4017's finding to the full failure surface.

---

Environment

• @deepseek-ai/dsh-agent-loop@0.1.1-rc.2
• Also verified on audit profile audit20260822
• Date: 2026-08-26

---

Detailed evidence chain and fix analysis follow in the comments below.

---

摘要

当工具调用经由任意一条失败路径（prepare 抛错 / dispatch 拒绝 / finalize 抛错）失败时，tool/call 已被写入，但 tool/result 永远没有写出。会话因此永久不可用——此后每一次请求都会被模型 API 以 INVALID_REQUEST (400) 拒绝。

引擎已经有恢复逻辑（appendSkippedToolCall，位于 dsh-agent-loop/lib/index.js:274-290），并且在 abort 路径上应用了它。但 failure 路径完全没有走这条逻辑——外层 catch (:252-255) 只 drain 掉 dispatches 然后重新抛出，从不写恢复结果。代码自己的 JSDoc (:159-160) 就记录了这种不对称："Scheduler failure drains dispatches without committing synthetic recovery results."

建议修复：在 failure 的 catch 路径中应用 appendSkippedToolCall——复用现有机制，无需新增代码路径。

触发条件

1. 工具调用进入调度器
2. 以下任一发生：prepare 抛错 / dispatch 拒绝 / finalize 抛错
3. tool/call 已持久化，tool/result 永远未写出
4. 会话被永久污染——无自动恢复

最小复现

// 1. 配置一个工具使其 ctx.tools[TOOL_RUNTIME_SCHEDULER] 为 undefined
//    （例如模块实例被拆分，或该 profile 未注册该工具）
// 2. 调用该工具 —— prepare() 在 :193 同步抛错
// 3. 观察：会话历史中出现了 tool/call 但无 tool/result
// 4. 再发送任意后续消息 → 模型 API 返回 400 INVALID_REQUEST
// 5. 会话永久不可用；不人工干预则无法恢复

相关 issue

• 工具调用失败留下悬挂 tool_calls,会话被 400 INVALID_REQUEST 永久卡死 #4017 报告了入口 1（prepare 抛错）。本报告补充了入口 2-3，并将"恢复机制不对称"识别为根因。并非重复——是把 工具调用失败留下悬挂 tool_calls,会话被 400 INVALID_REQUEST 永久卡死 #4017 的发现扩展到完整的失败面上。

---

详细证据链与修复分析见下方跟帖。

署名 / About this report

EN: Reported by the OfferKuai (Offer快) Team — an AI startup building full-lifecycle job-application services, guided by the belief that *"users need results, not repeated conversations." We use DeepSeek Harness as part of our daily development workflow; this report is our way of contributing back to the ecosystem.

ZH: 本报告由 OfferKuai（Offer快）团队提交 —— 一家专注 AI 全流程求职托管的创业团队，核心理念是「用户要的是结果，不是重复对话」。我们将 DeepSeek Harness 用于日常开发工作流，这份报告是我们对社区的回馈。

[yamingmou]

Evidence Chain — Three Failure Entry Points, One Recovery Gap

The invariant "every tool/call must be paired with a tool/result" is enforced on the abort path but NOT on the failure path. All three failure entries land in the same outer catch that never writes recovery.

Entry 1: prepare throws (synchronous)

@deepseek-ai/dsh-agent-loop/lib/index.js:193 (rc.2):

const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);

If ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined (split module instance, tool not registered for profile), prepare() throws synchronously. The error propagates directly to the outer catch (:252-255) without passing through the dispatch rejection handler. tool/call is already appended (:191), tool/result is never written.

This is the #4017 scenario.

Entry 2: dispatch rejects

@deepseek-ai/dsh-agent-loop/lib/index.js:197 (rc.2):

const promise = ctx.tools[TOOL_RUNTIME_SCHEDULER].dispatch(prepared.exec).then((outcome) => {

If dispatch rejects, the failure is recorded in schedulerFailures. Subsequent throwSchedulerFailure() calls (:235/237/246/248) throw, entering the same outer catch (:252-255). The call's slots[index] stays void 0, so commitReady skips it — tool/result is never appended.

Entry 3: finalize/finish throws inside commitReady

@deepseek-ai/dsh-agent-loop/lib/index.js:181 (rc.2):

const result = slot.needsPost ? await ctx.tools[TOOL_RUNTIME_SCHEDULER].finalize(slot.exec, slot.result) : ctx.tools[TOOL_RUNTIME_SCHEDULER].finish(slot.exec, slot.result);

A post-dispatch hook failure inside commitReady bubbles through fillPool's await commitReady() into the same outer catch. The slot being committed at that moment already has its tool/call appended (:191) but its result is not yet written (:182 runs after :181).

---

The Recovery Gap

The outer catch (:252-255) handles all three entries:

} catch (error) {
    schedulerFailure ??= { error };
    await Promise.allSettled(inFlight.values());
    throw schedulerFailure.error;
    // ← NEVER writes a recovery result for the already-appended tool/call
}

Contrast with the abort path (:257-258):

if (aborted) {
    for (const call of group.slice(started)) appendSkippedToolCall(session, turn, step, call.block);

The abort path applies appendSkippedToolCall at two layers (group-level :258, caller-level :139). The failure path applies it nowhere.

The JSDoc Documents This Asymmetry

@deepseek-ai/dsh-agent-loop/lib/index.js:159-160 (rc.2), runGroup's own JSDoc:

"Scheduler failure drains dispatches without committing synthetic recovery results."

This is not an accidental omission — it is the documented, implemented behavior. The design intent ("a scheduler failure is an engine-level fault, surface it loudly") is defensible in isolation — but it does not account for the consequence: an unpaired tool/call is durable, and the model API will reject every later request on that session forever. A loud failure at turn N becomes a permanently poisoned session at turn N+1, N+2, … with no automatic recovery path.

---

Conclusion: The engine already owns the exact recovery machinery (appendSkippedToolCall), applied on abort paths at two layers. The failure path bypasses all of them. Three distinct entries, one shared catch, zero recovery.

---

证据链 — 三个失败入口，一个共同的恢复缺口

"每个 tool/call 都必须配对一个 tool/result" 这条不变量，在 abort 路径上被强制保障，但在 failure 路径上完全没有。三条失败入口都落入同一个外层 catch，而它从不写恢复结果。

入口 1：prepare 同步抛错

若 ctx.tools[TOOL_RUNTIME_SCHEDULER] 为 undefined（模块实例被拆分、或该 profile 未注册该工具），prepare() 同步抛错。错误直接传播到外层 catch (:252-255)，不经过 dispatch 的拒绝处理器。tool/call 此时已被追加 (:191)，tool/result 永不写出。

这就是 #4017 报告的情形。

入口 2：dispatch 拒绝

若 dispatch 拒绝，失败被记入 schedulerFailures。后续 throwSchedulerFailure() 调用 (:235/237/246/248) 抛错，同样进入外层 catch (:252-255)。该调用的 slots[index] 保持 void 0，于是 commitReady 跳过它——tool/result 永不追加。

入口 3：finalize/finish 在 commitReady 内部抛错

commitReady 内部的后处理钩子失败，经由 fillPool 的 await commitReady() 冒泡到同一个外层 catch。此刻正在提交的那个 slot 的 tool/call 已追加 (:191)，但结果尚未写出（:182 在 :181 之后执行）。

---

恢复缺口

外层 catch (:252-255) 处理全部三条入口：

对比 abort 路径（:257-258）：

abort 路径在两层都应用了 appendSkippedToolCall（group 级 :258，caller 级 :139）。failure 路径一处都没用。

JSDoc 记录了这种不对称

这不是偶然遗漏——这是被文档化、被实现的行为。设计意图（"调度失败是引擎级故障，应当高声暴露"）单独看有道理——但它没有考虑后果：一个未配对的 tool/call 是持久化的，模型 API 会永远拒绝该会话之后的每一次请求。第 N 轮的高声失败，会变成第 N+1、N+2 … 轮永久被污染的会话，且没有任何自动恢复路径。

---

结论：引擎已经拥有现成的恢复机制（appendSkippedToolCall），并在 abort 路径的两层上都用了。failure 路径把它们全部绕开。三条独立入口，一个共享 catch，零恢复。

[yamingmou]

Suggested Fix (Updated)——Update to the Suggested Fix (Option A) posted earlier:

Option A: Append recovery tool/result in the failure catch path (Recommended)

@deepseek-ai/dsh-agent-loop/lib/index.js, modify the outer catch (:252-255):

// Current:
} catch (error) {
    schedulerFailure ??= { error };
    await Promise.allSettled(inFlight.values());
    throw schedulerFailure.error;
}

// Proposed (minimal, precise):
} catch (error) {
    schedulerFailure ??= { error };
    await Promise.allSettled(inFlight.values());
    // Synthesize a recovery result for every call that was *started*
    // (tool/call already durable at :191, callSeqs[i] set) but whose result was
    // never committed. `committed` advances ONLY after appendToolResult succeeds
    // (:185), so [committed, started) is exactly the "tool/call without
    // tool/result" set — covers ALL THREE entries:
    //   • prepare throws (:193)  → slots[i] still void 0, i >= committed
    //   • dispatch rejects (:204) → slots[i] still void 0, i >= committed
    //   • finalize/finish throws (:181, commitReady) → slots[i] NON-void but
    //     appendToolResult at :182 never reached, i >= committed
    // We append ONLY the result citing the EXISTING call seq — never call
    // appendSkippedToolCall, which would emit a SECOND tool/call (:275).
    const skippedResult = {
        content: [{ type: "text", text: "Error: tool call failed before a result was recorded" }],
        isError: true,
        error: {
            message: "tool call failed before a result was recorded",
            info: { name: "SchedulerError", code: TOOL_ABORTED_BEFORE_DISPATCH }
        }
    };
    for (let i = committed; i < started; i++) {
        appendToolResult(session, turn, step, group[i].block, skippedResult, callSeqs[i]);
    }
    throw schedulerFailure.error;
}

Why recommended:

• ✅ Reuses the recovery shape the engine already owns — appendSkippedToolCall (:274-290) shows the exact isError: true + structured error.info form; we mirror it but append only the result, because tool/call is already durable at :191
• ✅ Maintains the tool/call → tool/result pairing invariant on all three failure entries (prepare/dispatch/finalize)
• ✅ No new recovery concept — same pattern as the abort path (:258, :139), wired to the catch
• ✅ Avoids double-write: appendSkippedToolCall re-emits tool/call (:275); here the call is already logged, so we cite the existing seq via callSeqs[i]

Open question: Should the recovery error code distinguish "user aborted" from "engine failed"? (Currently reuses TOOL_ABORTED_BEFORE_DISPATCH for compilability; a distinct TOOL_FAILED_BEFORE_RESULT could separate them in telemetry.)

Note: This is a correction of the earlier Option A posted in this thread. The original version called appendSkippedToolCall() which would re-emit a second tool/call (:275) for an already-durable call — the fix above uses appendToolResult directly to avoid that double-write.

---

建议修复（更新版）

方案 A：在 failure catch 路径中追加恢复性 tool/result（推荐）

@deepseek-ai/dsh-agent-loop/lib/index.js，修改外层 catch（:252-255）：

// 当前：
} catch (error) {
    schedulerFailure ??= { error };
    await Promise.allSettled(inFlight.values());
    throw schedulerFailure.error;
}

// 提议（最小改动，精确修复）：
} catch (error) {
    schedulerFailure ??= { error };
    await Promise.allSettled(inFlight.values());
    // 为每个已启动（tool/call 在 :191 已落盘，callSeqs[i] 已设）但结果未提交的调用
    // 合成恢复结果。`committed` 仅在 appendToolResult 成功后推进（:185），
    // 因此 [committed, started) 恰好是"有 tool/call 无 tool/result"的集合，
    // 覆盖全部三个入口：
    //   • prepare 抛错（:193）→ slots[i] 仍 void 0，i >= committed
    //   • dispatch 拒绝（:204）→ slots[i] 仍 void 0，i >= committed
    //   • finalize/finish 抛错（:181，commitReady 内）→ slots[i] 非 void 但
    //     :182 的 appendToolResult 未执行，i >= committed
    // 只追加 result 并引用已有 call seq——不调用 appendSkippedToolCall，
    // 因为它会再写一条 tool/call（:275），导致重复。
    const skippedResult = {
        content: [{ type: "text", text: "Error: tool call failed before a result was recorded" }],
        isError: true,
        error: {
            message: "tool call failed before a result was recorded",
            info: { name: "SchedulerError", code: TOOL_ABORTED_BEFORE_DISPATCH }
        }
    };
    for (let i = committed; i < started; i++) {
        appendToolResult(session, turn, step, group[i].block, skippedResult, callSeqs[i]);
    }
    throw schedulerFailure.error;
}

推荐理由：

• ✅ 复用引擎已有的恢复形态——appendSkippedToolCall（:274-290）展示了精确的 isError: true + 结构化 error.info 形态；照搬该形态，但只追加 result，因为 tool/call 在 :191 已落盘
• ✅ 在全部三个失败入口（prepare/dispatch/finalize）上保障 tool/call → tool/result 配对不变量
• ✅ 无新增恢复概念——与 abort 路径（:258、:139）同一模式，只是接到 catch 上
• ✅ 避免重复写入：appendSkippedToolCall 会重发 tool/call（:275）；此处 call 已记录，通过 callSeqs[i] 引用已有 seq

开放问题：恢复错误码是否应区分"用户中止"与"引擎失败"？（当前复用 TOOL_ABORTED_BEFORE_DISPATCH 以保证可编译；可选新增 TOOL_FAILED_BEFORE_RESULT 在遥测中区分。）

说明：本帖修正了此前在本帖中发布的 Option A。原版本调用 appendSkippedToolCall() 会对已落盘的 call 重复写入 tool/call（:275）；修正版改为直接使用 appendToolResult 避免此问题。

[yamingmou]

Change from earlier version: The original Option A called appendSkippedToolCall() which re-emits tool/call at :275 — since the call is already durable at :191, that creates a duplicate. This version uses appendToolResult directly with the existing callSeqs[i], appending only the missing tool/result.

[xiaoshenming]

和 #1593 / #4309 同类：tool/call 已落盘、失败路径没写 tool/result，之后供应商永久 400。日志往往仍能加载。

dsh-session-surgeon 不会发明缺失的 tool/result。inspect / 导出可以定位那条悬空 call。若同时还报 seq gap / 缺 message.id，那些才能 dry-run 修。

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

[yamingmou]

Hi @xiaoshenming,

Thanks for confirming the family — agreed, #4017 / #1593 / #4309 / #4549 all share the same root invariant: tool/call durable, tool/result missing, permanent 400. Your breakdown of the three layers (recovery layer for #4309/#4549, serialization layer for #1593) is precise and matches our analysis. [#4017](#4017) is the original report by @snow-The that triggered our investigation — same dangling tool/call pattern, different entry point (prepare() throws when scheduler symbol is undefined).

Quick update: We just corrected our Suggested Fix (Option A) — the original code called appendSkippedToolCall(), which re-emits a second tool/call (:275). Since the call is already durable at :191, that's a double-write. The fix now uses appendToolResult directly, citing the existing seq. See the update comment above.

Two questions for you:

Your dsh-session-surgeon can inspect / export to locate dangling tool/call entries — that's valuable for diagnosis. But as you noted, it won't invent the missing tool/result. We're curious about:

1. Detection at inspect time: Could the tool flag a tool/call that has no corresponding tool/result as a warning during inspect? Even without auto-fix, surfacing "⚠️ N dangling tool/calls found — session will hit permanent 400 on next model request" would help users triage faster.
2. Prevention vs. repair: Our proposal puts the fix inside the engine (catch path synthesizes recovery results), so the invariant is maintained automatically — no user action needed. Your tool operates at the repair layer (post-hoc inspection). Do you see a way for these two approaches to complement each other? E.g., engine-side prevention for new sessions + surgeon-side repair for sessions already poisoned before the fix lands?

Our position: The engine already owns the recovery machinery (appendSkippedToolCall on the abort path at :258 and :139). The failure path just doesn't use it. Closing that gap is the minimal fix — and it makes the surgeon's job easier too, since there would be fewer poisoned sessions to diagnose.

Would appreciate your thoughts — especially on whether dsh-session-surgeon could add a "dangling call" warning to its inspect output.

---

@xiaoshenming 感谢确认家族关联——同意，#4017 / #1593 / #4309 / #4549 共享同一个根不变量：tool/call 已落盘、tool/result 缺失、永久 400。你对三个层的划分（#4309/#4549 = 恢复层失守，#1593 = 序列化层失守）很精确，与我们的分析一致。#4017 是 @snow-The 的原始报告，触发了我们的调查——同一悬空 tool/call 模式，不同入口（scheduler symbol 为 undefined 时 prepare() 抛错）。

快速更新：我们刚修正了建议修复方案（Option A）——原代码调用了 appendSkippedToolCall()，该函数内部会再写一条 tool/call（:275）。由于 call 在 :191 已落盘，这会导致重复写入。修正后改为直接用 appendToolResult，引用已有的 seq。详见上方更新评论。

想请教两个问题：

1. 检测能力：dsh-session-surgeon 在 inspect 时能否将没有对应 tool/result 的 tool/call 标记为 warning？即使不做自动修复，输出"⚠️ 发现 N 个悬空 tool/call——下次模型请求将永久 400"也能帮用户更快定位问题。
2. 预防 vs. 修复：我们的方案把修复放在引擎内（catch 路径自动合成恢复结果），不需要用户操作。你的工具在修复层做事后检查。你觉得这两种方式能互补吗？比如：引擎侧预防新产生的会话 + surgeon 侧修复在修复落地前已经被污染的会话？

我们的立场：引擎已经拥有恢复机制（appendSkippedToolCall 在 abort 路径的 :258 和 :139 上使用）。failure 路径只是没有用它。补上这个缺口是最小修复——也能让 surgeon 的工作更轻松，因为需要诊断的被污染会话会更少。

希望听听你的看法——特别是 dsh-session-surgeon 能否在 inspect 输出中增加"悬空 call"警告。

[xiaoshenming]

不是说会话医生有问题——谢谢把检测需求写清楚。

inspect 警告：会加，已经写进 main。 inspect / session_inspect 现在会把没有对应 tool/result 的 tool/call 标成 dangling-tool-call（含 seq + callId）。文件仍能加载，health 不再假装 ok。空 callId 也算悬空。repair 仍然不会编假 tool/result，也不会给空 callId 填 UUID。

预防 vs 修复：互补，不是二选一。

层	谁做	作用
引擎 failure catch	你们 Option A（appendToolResult 引用已有 seq，不要再走会二次 tool/call 的 appendSkippedToolCall）	新会话不再被毒
离线 inspect	surgeon	引擎补丁落地之前已经落盘的会话，用户能一眼看到「下次请求会 400」
离线 apply	surgeon 不做	编假 result 会把对账修得更假

所以：引擎侧最小修复关掉写入缺口；surgeon 负责已经中毒的日志的诊断。引擎修上之后，需要我们诊断的会话会变少——这正是我们想要的。

安装仍是：

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

然后 inspect <id>。issues 里会出现 dangling-tool-call: tool/call without tool/result: … — next model request will 400。

[yamingmou]

Thanks！