[Bug] A crashed tool call leaves an unresolved tool_use in history; the session then fails forever with "DeepSeek Messages tool calls need immediate results"

[sheldonzhang312-hub]

Environment

• DSH 0.1.6-alpha.2, macOS arm64
• Provider: deepseek-official, model deepseek-flash, reasoning effort high

Summary

When a turn dies while a tool call is in flight, the unfinished call stays in
the session history as a tool_use with no result. DeepSeek Messages
serialization then rejects every later turn with
DeepSeek Messages tool calls need immediate results (INVALID_REQUEST),
so the session can never recover. Only opening a brand-new session helps.

Steps to reproduce (logic-level)

1. Open a session where ask_user_question is available.
2. Have the agent emit ask_user_question and let that turn crash for any
   reason (we hit Cannot read properties of undefined (reading 'prepare');
   any equivalent crash should do).
3. Send any further user message.

Observed behavior

Every subsequent turn fails instantly with INVALID_REQUEST, before any new
tool call is made. Evidence from session.v3.jsonl:

• tool/call ask_user_question (callId call_00_rcuMRho9x0wEYkT0YVOd2872) has no matching tool result;
• later assistant/attempt entries fail with INVALID_REQUEST.

Root cause

packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117 throws
whenever any pending tool call is serialized, and :121 throws when history
ends with unresolved tools. There is no cleanup path for a tool call whose turn
crashed, so the dangling call permanently violates the "immediate results"
invariant.

Suggested fix

When a turn ends in error with unfinished tool calls, truncate or finalize
those calls (or offer a "truncate history" action) so the session can continue.

Related (context)

While reproducing we also saw Cannot read properties of undefined (reading 'prepare')
in tool scheduling (packages/core/tools/src/ptc.ts:615). Changing
TOOL_RUNTIME_SCHEDULER from Symbol(...) to Symbol.for(...) in
packages/core/tools/src/index.ts:463 fixed it locally; mentioning in case it
is a real cross-instance issue rather than an artifact of our self-built copy.

[yunshu33]

Additional report: same failure on Windows x64 source build

Environment

DSH	0.1.6-alpha.2 (ddefc45fbc), source checkout, branch master
Launch	node --import tsx/esm apps/cli/src/bin.ts web
OS	Windows 10 Pro 22H2, build 19045, x64
Node	v24.18.0
Provider / model	deepseek-official / deepseek-flash, reasoning effort high
Agent preset	standard
Tool mode	native (26 tools, no run_code)

Summary

Same as reported: a turn dies while a tool call is in flight, the unfinished call stays in history as a tool_use with no result, and every later turn fails instantly with DeepSeek Messages tool calls need immediate results (INVALID_REQUEST). The session never recovers; only a new session works.

Tools that errored

Three sessions, three different tools — so this is not tool-specific. In all three the crash is on the first tool call of a turn, before any tool body runs.

Session	Crashing tool	Turn / step	Crash error
session-69a110fd-…	grep	turn 6, step 1	Cannot read properties of undefined (reading 'prepare') (UNKNOWN)
session-c607c71a-…	pwsh	turn 1, step 1	same
session-40158bc7-…	subagent	turn 2, step 1	same

In session-69a110fd, the preceding 388 tool calls across turns 1–5 all completed normally — so the condition is time-varying, not a bad configuration.

Observed behavior

• Every later turn fails instantly, before any new tool call is made. We saw two consecutive failures (turns 7 and 8) in session-69a110fd.
• The lockout is durable in the log. One of the sessions (session-40158bc7) still failed at turn 3 after we rolled the build back to 0.1.6-alpha.1 — a new build alone does not bring a poisoned session back.

Evidence from session.v3.jsonl

Log shape is identical in all three:

assistant/message   content: [ …, {type:'tool-call', id:'call_00_…'}, {type:'tool-call', id:'call_01_…'} ]
tool/call           { callId: 'call_00_…', name: 'grep' }     <-- only the FIRST call gets a tool/call
step/end            { turn: 6, step: 1 }
turn/end            { reason: { kind: 'error', error: { message: "Cannot read properties of undefined (reading 'prepare')", code: 'UNKNOWN' } } }
… next user message …
assistant/attempt   finish.reason.failure = { message: "DeepSeek Messages tool calls need immediate results", code: 'INVALID_REQUEST' }
turn/end            { reason: { kind: 'error', error: { …INVALID_REQUEST… } } }

Session	tool/call	tool/result	tool-call blocks in the crashing message	Unresolved tool_use
session-69a110fd	389	388	2	2
session-c607c71a	1	0	2	2
session-40158bc7	1	0	1	1

The model emitted N tool calls in one assistant message; the harness wrote a tool/call for the first one and then died, leaving the rest with neither a tool/call nor a tool/result.

Note on prepare

With mode: native the failing read is packages/core/agent-loop/src/tool-calls.ts:170:

callSeqs[index] = appendToolCall(session, turn, step, call.block)   // :168  durable tool/call written
started++                                                          // :169
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)  // :170  THROWS

So the same symbol miss also occurs on the native path, not only at ptc.ts:615.

That call site is also why the log cannot self-repair: on the scheduler-failure path the catch block rethrows at :235 and the only synthetic-result recovery (appendSkippedToolCall, if (aborted) at :238) is never reached — and even there the loop starts at group.slice(started), skipping the call that was already appended at :168.

[Sheldondxx]

Confirmed on Linux, DSH 0.1.6-alpha.2 (master@ddefc45fbc), web profile — a turn that ended with kind: "error" while a tool call was in flight (the reading 'prepare' crash from #7265, in our case) left the advertised tool calls unresolved, and every later turn died at serialization with DeepSeek Messages tool calls need immediate results.

One data point on the crash-vs-error distinction: interruptedTurnClosers (packages/core/session/src/repair.ts) only appends the synthetic TOOL_NOT_STARTED / TOOL_OUTCOME_UNKNOWN results when the log ends mid-turn. Here the turn/end was written (with the error reason), so the log counts as balanced and no repair ever runs — even though the assistant message still advertises unresolved calls. That gap is what makes the session permanently unrecoverable from the app's perspective.

We recovered the poisoned session by hand, replaying exactly what interruptedTurnClosers would have written, in case it helps others until a fix lands:

1. Stop every dsh process holding the session lock.
2. Back up ~/.dsh/sessions/<workspace-key>/<session-id>/session.v3.jsonl.zstd.
3. Decompress (zstd -d), and for each tool-call block in the last assistant/message that has no matching tool/result, insert a synthetic tool/result event immediately after its tool/call event (or after the assistant message if the call never started):
   • turn/step of the open step, surfaceOp: "append", seq continuing the log, renumbering later events.
   • Started call: error: { name: "ToolOutcomeUnknownError", code: "TOOL_OUTCOME_UNKNOWN" } with sourceEventSeqs: [<tool/call seq>].
   • Never-started call: error: { name: "ToolNotStartedError", code: "TOOL_NOT_STARTED" }, message id interrupted-tool-result-<callId>-<seq> (the canonical repair identity checked by the v3 format validators).
   • Message content: one tool-result block with isError: true and the same explanatory text repair.ts uses.
4. Recompress with the header line as its own first zstd frame — the persistence layer asserts first frame is not exactly one header line, so a plain single-frame zstd recompress corrupts the file from its point of view. We did: head -1 log.jsonl | zstd > out.zst && tail -n +2 log.jsonl | zstd >> out.zst.

After that the session resumes and new turns complete normally. Obviously this is surgery on a durable log, not a supported path — but it confirms the repair events themselves are accepted by the v3 validators and the runtime invariant checks, so extending the crash-repair pass to error-terminated turns with pending calls should be a safe fix.

[sheldonzhang312-hub]

Root cause confirmed + one-line fix (PR channel is disabled on this repo, so posting it here)

I can confirm the crash root cause for both dispatch paths reported above (ptc.ts and tool-calls.ts): TOOL_RUNTIME_SCHEDULER is defined in packages/core/tools/src/index.ts with Symbol():

export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')

Symbol() has per-module-instance identity. When the tools package ends up in more than one bundle/module graph, consumers look the scheduler up with a different symbol identity than the one used to register it, so registry[TOOL_RUNTIME_SCHEDULER] is undefined and the first tool call of a turn throws Cannot read properties of undefined (reading 'prepare'). That also matches the reported time-varying, tool-agnostic behavior.

Fix (one line):

export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

Symbol.for() resolves through the global symbol registry, so the key survives across module instances and bundles. This is already the convention for the repo's other cross-package symbols (dsh.subagent.*, dsh.typert.owned-value).

I tried to open a PR, but pull requests are disabled on this repository, so the patch is available as a branch:

• Fork: https://github.com/sheldonzhang312-hub/deepseek-harness
• Branch: fix/tool-runtime-scheduler-symbol (single-commit, one-line change)
• Diff: sheldonzhang312-hub@4dcf2d1

Verified locally: macOS (arm64) source build, 0.1.6-alpha.2 — with this patch and a rebuild, sessions that previously died on the first tool call complete normally. It fixes the crash; the repair-path gap for already-poisoned sessions described by @Sheldondxx is a separate concern that still needs a fix.