Session history permanently poisoned with unanswered assistant tool_calls after tool-scheduler failure (400 'insufficient tool messages' on every retry)

[zttt04]

Summary

After a tool-call turn fails with a scheduler error, the session history can permanently contain an assistant message with tool_calls that have no matching tool result messages. From that point on, every LLM request in that session is rejected by the DeepSeek (OpenAI-compatible) API 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)

This bricks the conversation: the error repeats on every retry/resume until the session is discarded or manually repaired.

Environment

• @deepseek-ai/dsh 0.1.0-rc.7, desktop GUI (Microsoft Edge WebView client) + dsh web server
• Provider: deepseek-official (deepseek-v4-flash), chat-completions wire route (dsh-llm-deepseek)

Reproduction evidence (from session logs, ~/.dsh/sessions/*/session.jsonl.zstd)

Session A (also seen in a second session):

1. Turn 2: model emits 2 parallel tool calls (bash + grep). The assistant message is committed with tool_calls; one tool/call event is recorded for bash; the second call is never dispatched.

2. The turn then ends in error (never produces any tool/result):

   {"type":"turn/end","data":{"turn":2,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}

3. From then on, every subsequent turn fails with the 400 above:

   {"type":"turn/end","data":{"turn":3,"reason":{"kind":"error","error":{"message":"An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. ..."}}}}

Root cause

In dsh-agent-loop's tool-call scheduler (runGroup), when the scheduler throws (here: ctx.tools[TOOL_RUNTIME_SCHEDULER] was undefined when calling .prepare(...), TypeError: Cannot read properties of undefined (reading 'prepare')):

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

The tool/call event was already appended (before prepare), but the failure path intentionally does not fabricate results — the code comment says: "A terminal scheduler failure preserves already-recorded tool/call events without fabricating results." The abort path does fabricate results (appendSkippedToolCall), but the error path does not.

Net effect: the persisted conversation history contains an assistant message with tool_calls and no answering tool messages. dsh-llm-deepseek/serializeMessages serializes that history verbatim to the wire, so the provider rejects the request. This also permanently poisons the session for compaction/resume.

Suggested fixes

1. Scheduler failure path: on scheduler failure, close out every started-but-unanswered call with a synthetic error tool/result (mirroring appendSkippedToolCall), so the history never retains dangling tool_calls.
2. Defensive wire sanitization (belt-and-suspenders): in serializeMessages, append synthetic {role:"tool", tool_call_id} messages for any assistant tool_calls id that never receives a tool-result, so a malformed stored history can never produce this provider 400.
3. Optionally: detect dangling tool calls at session load/continue and repair.

Workaround (users)

Start a new conversation, or manually append synthetic tool/result events (with isError: true) to the session JSONL for each unanswered tool_call_id.

[denial123789]

The rc.7 source confirms the key recovery gap here. runGroup() appends tool/call before scheduler prepare(). Its cancellation path closes skipped calls with ordered error results, but the scheduler-failure catch waits for in-flight work and rethrows without balancing the remaining calls. The Agent Loop can then append turn/end { error }.

That closed turn explains why cold resume does not heal this case. interruptedTurnClosers() synthesizes TOOL_NOT_STARTED / TOOL_OUTCOME_UNKNOWN results only while an open tail turn exists. Once turn/end has been persisted, it returns no closers even if the provider transcript still has unanswered assistant call IDs. The DeepSeek serializer then preserves the message order and does not invent missing tool messages, so the next request repeats the same 400.

For user recovery I would avoid hand-editing the live compressed artifact. Stop retries and all writers, preserve the original, classify every assistant call id against durable tool/call and tool/result events, verify external state for any recorded side-effecting call, then continue in a fresh Session with a reviewed summary. A missing result must not be interpreted as a missing effect.

For the durable fix, the loop boundary should close every requested call exactly once before the error turn ends: no durable start → TOOL_NOT_STARTED; durable start without result → TOOL_OUTCOME_UNKNOWN. Keep model order and preserve the original scheduler error as the controlling turn failure. A load-time audit can address existing poisoned closed turns; a wire-only sanitizer is containment because it lacks evidence about whether a tool ran.

Source-pinned lifecycle trace, recovery decision table, and regression gates: https://sandbaseai.github.io/deepseek-harness-handbook/insufficient-tool-messages.html

Disclosure: independent SandBase community handbook, not official DeepSeek documentation.