[BUG] 400 invalid_request_error with Experimental Parallel Tool Calls after 20-30 conversation turns

[SilentFlower]

Problem (one or two sentences)

When using the Anthropic provider with the experimental "Parallel tool calls" feature enabled, a bug may occur after the number of conversation turns reaches a certain threshold (approximately 20-30 turns).

The API call fails and returns a 400 invalid_request_error.

Error Response:

{
"type": "error",
"error": {
"type": "invalid_request_error",
"message": "messages.70: tool_use ids were found without tool_result blocks immediately after: toolu_01FZKGcgUxLCjjJqsvMMFyHH. Each tool_use block must have a corresponding tool_result block in the next message."
},
"request_id": "req_011CVdnBbidP19zWhjmu5Rj5"
}

Context (who is affected and when)

When using the Anthropic provider with the experimental "Parallel tool calls" feature enabled, a bug may occur after the number of conversation turns reaches a certain threshold (approximately 20-30 turns).

Reproduction steps

0.use Anthropic provider
1.enable tool call native
2.enable experimental "Parallel tool calls" feature
3.approximately 20-30 turns

Expected result

Engage in a normal conversation

Actual result

400 error

Variations tried (optional)

No response

App Version

3.34.8

API Provider (optional)

Anthropic

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I'm exploring a potential fix for this issue with Anthropic's parallel tool calls feature. The error indicates that tool_use blocks are not being properly matched with tool_result blocks in the message history after multiple conversation turns. I'll investigate the message handling logic and open a PR to share progress.

[roomote]

I've opened PR #9701 with a fix for this issue: #9701

The root cause was a mismatch between the API-side configuration (disable_parallel_tool_use) and the client-side handling of tool executions. When parallel tool calls were enabled in settings, the API would send multiple tool_use blocks, but the client would only execute the first one and generate error tool_results for the rest, causing the accumulation of mismatched blocks over multiple conversation turns.

The fix ensures both the API and client use the same parallelToolCallsEnabled flag based on the MULTIPLE_NATIVE_TOOL_CALLS experiment setting. This prevents the tool_use/tool_result mismatch that was causing the 400 error.

All tests pass and the solution maintains backward compatibility. Feedback welcome!

[SilentFlower]

roo_task_nov-30-2025_7-59-48-pm.md

[SilentFlower]

I think it might be because the task has reached the context limit, which requires compression or truncation.

[daniel-lxs]

Hey, can you export the task an share it here? Did it happen after condensing?

[SilentFlower]

Hey, can you export the task an share it here? Did it happen after condensing?

I believe this is happening after the compression stage. You can check the information I sent above—I've already exported the 'task'.

[SilentFlower]

Hey, can you export the task an share it here? Did it happen after condensing?

roo_task_nov-30-2025_10-59-35-pm.md