[Bug] Session becomes permanently un-resumable after a turn ends in error with an unrecorded tool call

[YunSao2035]

Summary

When the harness fails mid tool-execution (e.g. the tool runtime scheduler becomes unavailable and ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined, throwing Cannot read properties of undefined (reading 'prepare')), the affected turn is closed with reason: { kind: "error" } without a tool/result for the already-recorded tool/call. From that point on the session can never be resumed: every new message re-sends a transcript that ends with an assistant tool_calls block that has no matching tool result, and the provider API rejects it with:

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)  [400 INVALID_REQUEST]

This persists across app restarts — the session is effectively bricked, while other sessions are unaffected.

Root cause analysis

The crash-recovery repair in dsh-session (interruptedTurnClosers, lib/types/repair.js) only synthesizes interrupted-tool-result events for an open tail turn:

case "turn/end":
    openTurn = null;
    openStep = null;
    pendingCalls.clear();
    break;

Because the crashed turn was already closed with a turn/end (reason: error), the pending call is cleared and never recovered. The log then contains assistant/message (with a tool-call block) → tool/call → (no result) → user/message …, which is not a provider-valid transcript.

Additionally, dsh-agent-loop's tool-call scheduling deliberately does not fabricate synthetic results on scheduler failure (see the docstring in the executeToolCalls section: "An internal scheduler failure … rejects with the first failure without fabricating tool results"), so the missing result is never written at crash time either.

Suggested fix

• On resume, extend interruptedTurnClosers (or add a parallel pass) to also match unmatched tool calls in the last closed turn when that turn ended with reason.kind === "error", appending the same interrupted-tool-result events the open-turn path generates; or
• In executeToolCalls, when a scheduler failure occurs after tool/call was durably recorded, append an error tool/result for the affected calls before failing the turn.

Repro notes

• Trigger: make the tool runtime scheduler unavailable while a tool call is executing (in our case this happened while node_modules files were being replaced while the app was running and the hot-reload swapped the context, leaving ctx.tools undefined at step execution time).
• Consequence: the first message after restart in the same session fails with the 400 above and repeats forever.
• Workaround used: manually injected an interrupted-tool-result event (same shape the repair path generates: ToolOutcomeUnknownError / TOOL_OUTCOME_UNKNOWN) into the session log right after the dangling tool/call, resequenced the remaining event seqs, and re-framed the zstd JSONL artifact (first frame must contain exactly the header line). The session then resumes normally.

Environment

• dsh / dsh-session / dsh-agent-loop 0.1.0-rc.6 (deepseek-harness), web profile, Windows.

[zoahdev]

Confirmed - this is the #1959/#1697 family's durable scar: the original crash (ctx.tools[TOOL_RUNTIME_SCHEDULER] undefined, reading 'prepare') is fixed by our fix/tool-runtime-scheduler-symbol-for branch, but sessions already bricked by it stay bricked because crash-recovery only repairs an OPEN tail turn.

Two things you can do right now

1. Recover the content with dsh-shelf v0.6.0:

   npx dsh-shelf verify        # finds orphan tool calls / unfinished turns
   npx dsh-shelf rescue <id>   # exports the transcript even though it is un-resumable

   Your "precious context" is still in the JSONL - rescue gets it out as Markdown.
2. For the provider-valid transcript issue: the repair path you quoted (interruptedTurnClosers in dsh-session repair.js) should also close a CLOSED error turn's pending calls by synthesizing interrupted-tool-result events right before that turn's turn/end - not just for an open tail turn. The log then stays provider-valid and the session remains resumable.

Happy to prepare that repair extension as a cherry-pick-ready branch (same queue as our #1697/#2002/#1997 fixes) - it is the mechanism-level completion of this whole family.

[Electricitysheep]

错误结束 + 未记录 tool call → 会话永久不可恢复——和 #1841/#1473 同族（状态不一致家族），rc 期最该修的稳定性问题之一。

临时只能开新会话；官方应修"失败时清理/回滚 tool call 状态"。会话恢复坑 FAQ 有：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md

[YunSao2035]

Update — root cause found (environment-side, plus an upstream hazard). The ctx.tools undefined crash in our deployment was caused by pnpm hoisting an old copy of @deepseek-ai/dsh-tools (0.0.1-rc.1, pulled in by a third-party plugin built against that version) into the profile root node_modules/@deepseek-ai/. Two copies of dsh-tools then exist at runtime; TOOL_RUNTIME_SCHEDULER is a per-module Symbol, so the agent loop looks up the scheduler on an instance registered by the other copy — ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined and tool execution fails with Cannot read properties of undefined (reading 'prepare') on resumed sessions, across restarts. Removing the hoisted old copy from the profile root fixes it (plugin deps under .pnpm are unaffected).

Upstream hazard: a plugin declaring an older @deepseek-ai/dsh-tools dependency can silently break tool execution for the whole profile when pnpm hoists it. Worth considering: (1) a versioned/namespaced scheduler symbol, or (2) validating/refusing mismatched dsh-tools copies at boot.

[YunSao2035]

Practical confirmation of the repair direction. We recovered a fully bricked session by hand-writing exactly what your repair path produces: an interrupted-tool-result (ToolOutcomeUnknownError / TOOL_OUTCOME_UNKNOWN) inserted immediately after the dangling tool/call, then resequencing every subsequent event (including packed chunk rows' seq0 and sourceEventSeqs references), and re-encoding the zstd JSONL artifact. After that the session resumed normally and executed tools successfully across several subsequent runs — so extending interruptedTurnClosers to also cover error-ended turns (not just open tail turns) does fully restore such sessions.

One caveat for whoever implements it: our first rewrite compressed the whole log into a single zstd frame and the app refused to boot with corrupt Zstandard session log: first frame is not exactly one header line — the recovery writer must preserve the header-only first frame layout.