fix: wait for all tool results before setting userMessageContentReady (EXT-693) #11091
Conversation
… (EXT-693) When multiple parallel tools are executed, the message queue was proceeding prematurely because userMessageContentReady was set to true when reaching the last content block, before all tool_result blocks were pushed to userMessageContent. This fix adds a helper function areAllToolResultsCollected() that: - Counts tool_use and mcp_tool_use blocks in assistantMessageContent - Counts tool_result blocks in userMessageContent - Only returns true when all tool_use IDs have matching tool_result IDs The userMessageContentReady flag is now only set to true when: 1. All content blocks are complete (no partial blocks) 2. All tool_use blocks have corresponding tool_result blocks 3. AND the stream is complete or aborted This prevents the message queue from sending messages before all parallel tool results are collected.
Review completed. All previously flagged issues have been addressed.
Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues. |
| // CRITICAL: For parallel tool execution, we must verify all tool results | ||
| // are collected before signaling ready. Without this check, the message | ||
| // queue could proceed before all tool_result blocks are in userMessageContent. | ||
| if (areAllToolResultsCollected(cline)) { |
There was a problem hiding this comment.
The PR description states that userMessageContentReady should only be set when the stream is complete or aborted (condition 3). However, this line only checks areAllToolResultsCollected(cline) without also checking didCompleteReadingStream, unlike lines 120 and 1052 which correctly check both conditions. This inconsistency could lead to premature signaling if we're at the last currently-known block and all tool results are collected, but the stream is still active and more tool_use blocks are incoming.
| if (areAllToolResultsCollected(cline)) { | |
| if (cline.didCompleteReadingStream && areAllToolResultsCollected(cline)) { |
Fix it with Roo Code or mention @roomote and request a fix.
| // Even if the tool executed, userMessageContentReady should NOT be true | ||
| // because the stream hasn't completed yet (more content may arrive) | ||
| // Note: The fix specifically checks both conditions | ||
| }) |
There was a problem hiding this comment.
This test describes the expected behavior in comments but lacks an actual assertion. The comment says "userMessageContentReady should NOT be true because the stream hasn't completed yet" but the test never verifies this. Without an assertion, this test will always pass regardless of the actual implementation behavior.
| // Even if the tool executed, userMessageContentReady should NOT be true | |
| // because the stream hasn't completed yet (more content may arrive) | |
| // Note: The fix specifically checks both conditions | |
| }) | |
| // Even if the tool executed, userMessageContentReady should NOT be true | |
| // because the stream hasn't completed yet (more content may arrive) | |
| // Note: The fix specifically checks both conditions | |
| expect(mockTask.userMessageContentReady).toBe(false) |
Fix it with Roo Code or mention @roomote and request a fix.
Fixed the reported issues. All local checks passed. |
Fixes the issue where the message queue sends messages prematurely during parallel tool execution.
Problem
When multiple parallel tools are being executed, the message queue was sending messages before all tool results were complete. The
userMessageContentReadyflag was set totruewhen reaching the last content block, before alltool_resultblocks were pushed touserMessageContent.Root Cause
In
presentAssistantMessage.ts, theuserMessageContentReadyflag was set totruebased only on whether we had reached the last content block index. This happened before all parallel tools had completed theirpushToolResult()calls.Solution
Added a helper function
areAllToolResultsCollected()that:tool_useandmcp_tool_useblocks inassistantMessageContenttool_resultblocks inuserMessageContenttrueonly when alltool_useIDs have matchingtool_resultIDsThe
userMessageContentReadyflag is now only set totruewhen:tool_useblocks have correspondingtool_resultblocksTesting
presentAssistantMessage-parallel-tools.spec.tsFiles Changed
src/core/assistant-message/presentAssistantMessage.ts- AddedareAllToolResultsCollected()helper and updated the three locations whereuserMessageContentReadyis setsrc/core/assistant-message/__tests__/presentAssistantMessage-parallel-tools.spec.ts- New test file for parallel tool execution timingView task on Roo Code Cloud
Important
Fixes premature message sending by ensuring all tool results are collected before setting
userMessageContentReadyduring parallel tool execution.userMessageContentReady.areAllToolResultsCollected()inpresentAssistantMessage.tsto verify tool results collection.presentAssistantMessage-parallel-tools.spec.tsto test parallel tool execution timing.userMessageContentReadyis only set when all conditions are met.presentAssistantMessage.ts: AddsareAllToolResultsCollected()and updatesuserMessageContentReadylogic.presentAssistantMessage-parallel-tools.spec.ts: New test file for parallel tool execution.This description was created by
for ace2500. You can customize this summary. It will automatically update as commits are pushed.