Interrupted tool calls permanently corrupt session history (orphaned tool_use without tool_result) #21326

Activity

1. liqiyuan3

   added

   bugSomething isn't workingSomething isn't working

   on Apr 7, 2026
2. github-actions

   assigned

   rekram1-node

   on Apr 7, 2026
3. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   windows

   on Apr 7, 2026
4. github-actions commented on Apr 7, 2026

   

   github-actionsBot

   on Apr 7, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • messages.87: tool_use ids were found without tool_result blocks immediately #10616: Same error tool_use ids were found without tool_result blocks immediately after
   • AI_APICallError: tool_use ids were found without tool_result blocks immediately after #1662: Same tool_use ids were found without tool_result blocks immediately after error

   If your issue is distinct or adds new context not covered by the above, please clarify the differences so it can be tracked separately.
5. bvironn commented on Apr 11, 2026

   

   bvironn

   on Apr 11, 2026

   More actions

   This affects me as well — v1.4.3, WSL2/Linux, Claude Opus 4.6 via Anthropic API. Sessions become permanently unrecoverable once hit.

   Regarding the bot's duplicate flag: this is the same symptom as #1662 and #10616, but the root cause has multiple entry points. The partial fixes applied so far address individual vectors but miss the systemic issue. Adding source-level analysis below.

   ---

   Healing logic exists but is insufficient

   There IS healing logic in message-v2.ts (lines 779-790) that catches pending/running tool calls and converts them to output-error parts:

   if (part.state.status === "pending" || part.state.status === "running")
     assistantMessage.parts.push({
       type: ("tool-" + part.tool),
       state: "output-error",
       toolCallId: part.callID,
       input: part.state.input,
       errorText: "[Tool execution was interrupted]",
     })

   And processor.ts (lines 489-512) marks interrupted tool calls as status: "error" with metadata: { interrupted: true } during cleanup. All four ToolState values (pending, running, completed, error) are handled in toModelMessages.

   Despite this, the bug persists because three code paths bypass the healing entirely.

   Vector 1 — normalizeMessages in transform.ts (lines 56-74)

   For Anthropic/Bedrock providers, messages with empty content after filtering get dropped:

   const filtered = msg.content.filter((part) => {
     if (part.type === "text" || part.type === "reasoning") {
       return part.text !== ""
     }
     return true
   })
   if (filtered.length === 0) return undefined // entire message removed

   This runs AFTER convertToModelMessages has already separated tool_use and tool_result into distinct ModelMessage entries. If a message in the ModelMessage[] chain gets eliminated here, it breaks the tool_use → tool_result pairing that the Anthropic API requires.

   Vector 2 — Error-skip in message-v2.ts (lines 697-705)

   if (msg.info.error && !(
     MessageV2.AbortedError.isInstance(msg.info.error) &&
     msg.parts.some((part) => part.type !== "step-start" && part.type !== "reasoning")
   )) {
     continue // entire assistant message skipped
   }

   When a previous assistant message failed with an APIError (including this exact tool_use without tool_result error), the message is skipped entirely on the next attempt. But its tool parts may have already influenced the ModelMessage[] chain via convertToModelMessages. The skip removes the message but not its downstream effects.

   Vector 3 — Lost step boundaries during retries (#16749)

   When the finish-step handler throws during a retryable error, step-finish for step N and step-start for step N+1 are never persisted. Both steps' content merges into a single DB message. On replay, convertToModelMessages produces interleaved tool_use/text/reasoning content in a single assistant block — which Anthropic rejects. #16749 documents this in detail with SQL evidence from a real session.

   The retry policy doesn't help

   In retry.ts, retryable() returns undefined for non-retryable errors. Anthropic's 400 Bad Request (isRetryable: false) means the corrupted request fails permanently on first attempt — no retry, no recovery.

   This is a long-standing systemic issue

   This has been open since #1662 (February 2026). Related issues include #8377, #10616, #16749, #17065, #14367, #21489, #2720, #5750, #2214, #8312, #8010. Partial fixes have been applied to individual vectors, but the core problem persists because each fix targets one entry point while the others remain open.

   Suggested fix: post-transform validation at the ModelMessage[] level

   The healing logic in toModelMessages and the cleanup in processor.ts work at the part level — before the data passes through convertToModelMessages and normalizeMessages. All three vectors corrupt the data after that point.

   The fix that catches all three vectors is a validation pass on the final ModelMessage[] array, after both convertToModelMessages and normalizeMessages have run. Pseudocode:

   function ensureToolResultIntegrity(messages: ModelMessage[]): ModelMessage[] {
     // 1. Collect all tool_use IDs from assistant messages
     // 2. Collect all tool_result IDs from tool messages
     // 3. For any tool_use ID without a matching tool_result:
     //    - Inject a synthetic tool_result with error content, OR
     //    - Remove the orphaned tool_use block
     // 4. Ensure no assistant message has text/reasoning after tool_use
     //    (split into separate messages if needed)
     return sanitized
   }

   This is the only point in the pipeline that sits downstream of all three corruption vectors. Fixing individual vectors is still worthwhile, but without this safety net, new edge cases will keep producing the same symptom.
6. rekram1-node commented on Apr 16, 2026

   

   rekram1-node

   on Apr 16, 2026

   Contributor

   More actions

   fix: 348a849

   👍React with 👍1Reacted by liqiyuan3
7. rekram1-node

   closed this as completedon Apr 16, 2026
8. phazei commented on May 5, 2026

   

   phazei

   on May 5, 2026

   More actions

   Totally not fixed

   👍React with 👍2Reacted by Douglas Mendes and Kirill German