fix(core): repair interleaved text/tool-call parts in assistant messages

[bil9148]

Issue for this PR

Closes #10616, #8377, #1662, #2720, #2214, #5750

Related: #4802, #8312, #10673, #7002

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

I kept hitting the tool_use ids were found without tool_result blocks immediately after error in my sessions. Once it happens, every subsequent message fails too — the only workaround is reverting the last message or starting a new chat. Extremely disruptive.

I dug into the actual API request payload from the logs and found that the tool_use/tool_result pairing was actually correct — all IDs matched. The real problem was the ordering of content parts within assistant messages.

The AI SDK's convertToModelMessages merges multi-step conversations and can produce assistant messages like:

[text, tool_use, tool_use, text, tool_use]

That second text block sitting between tool_use blocks causes Anthropic's API to think the tool-calling turn ended early, so it sees the first two tool_use IDs as orphaned from their tool_result blocks.

The fix adds repairAssistantMessages() in ProviderTransform.message() that:

1. Reorders assistant message content so all text/reasoning parts come before all tool-call parts
2. As a secondary safety net, injects synthetic tool-result blocks for any genuinely missing tool-results (handles edge cases like process crashes mid-tool-execution)

It also logs a warning when it makes repairs so the issue is observable in ~/.local/share/opencode/log/.

I verified the root cause by extracting messages[29] from the error's requestBodyValues in the log file. The content parts were [text, tool_use, tool_use, text, tool_use] — the interleaving was clearly visible. After the fix, the same session works fine.

How did you verify your code works?

• Reproduced the error in my session, applied the fix, retried the exact same failing message — it worked immediately
• 5 new test cases covering: interleaved reordering, orphaned tool-call injection, partial patching of existing tool messages, and no-op when messages are already correct
• 2 existing tests updated to account for the new safety net
• All 107 tests pass, typecheck clean

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• fix: handle dangling tool_use blocks for LiteLLM proxy compatibility #8497 - "fix: handle dangling tool_use blocks for LiteLLM proxy compatibility"
  • This appears related as it also addresses orphaned/dangling tool_use blocks, though it may be specific to LiteLLM proxy compatibility. The current PR (fix(core): repair interleaved text/tool-call parts in assistant messages #14456) takes a broader approach by repairing interleaved text/tool-call parts in assistant messages as a general safety net.

The other PRs found (#14393, #8888) appear less directly related as they focus on different aspects (thinking blocks and message conversion safeguards respectively).

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[alexyaroshuk]

We should try to avoid using the 'else' statements:
https://github.com/anomalyco/opencode/blob/dev/CONTRIBUTING.md#style-preferences
Could this be reworked?