fix: correct tool_use_id mismatch when editing messages in completed tasks

[daniel-lxs]

Summary

Fixes the "unexpected tool_use_id found in tool_result blocks" error that occurred when editing messages in completed tasks.

The Problem

When a user edited a message in a completed task:

1. API history contains an assistant message with tool_use blocks (e.g., id=A)
2. The user's response was removed during editing
3. A new response flow could generate different tool IDs (id=B)
4. The tool_result used id=B, but the API expected id=A
5. This caused the 400 error: unexpected tool_use_id found in tool_result blocks

The Solution

Added getValidatedToolUseId() function in presentAssistantMessage.ts that:

1. Detects edit scenarios by checking if the last message in API history is an assistant message (waiting for tool_result) vs a user message (normal flow)
2. Finds unmatched tool_use blocks and uses their correct IDs
3. Preserves original IDs during normal conversation flow

How it works:

• Normal flow (last message = USER): Use current streaming ID (it will be added to history)
• Edit flow (last message = ASSISTANT): Use ID from API history to match existing tool_use

Changes

• Added getValidatedToolUseId() function to validate and correct tool IDs
• Updated pushToolResult to use validated IDs
• Handles edge cases: multiple tools, matching by name, graceful fallbacks

Testing

The fix handles:

• ✅ Message edit scenarios
• ✅ Task resumption/rehydration
• ✅ Multiple tool calls in the same conversation
• ✅ Prevents the original "400 unexpected tool_use_id" error

---

Important

Fixes tool_use_id mismatch error in completed task message edits by validating tool IDs in presentAssistantMessage.ts.

• Behavior:
  • Adds getValidatedToolUseId() in presentAssistantMessage.ts to correct tool_use_id mismatches when editing messages in completed tasks.
  • Updates pushToolResult in presentAssistantMessage.ts to use validated tool IDs.
• Functionality:
  • Detects edit scenarios by checking the last message role in API history.
  • Matches tool_use blocks by ID or name, with fallbacks for unmatched cases.
  • Ensures correct tool_use_id is used in tool_result blocks to prevent 400 errors.
• Testing:
  • Handles message edits, task resumption, multiple tool calls, and prevents original 400 error.

^{This description was created by for 74b5eb4. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Rooviewer   See task on Roo Cloud

Review completed. No issues found.

The implementation correctly addresses the tool_use_id mismatch issue when editing messages in completed tasks. The getValidatedToolUseId() function properly detects edit scenarios by checking the last message role in API history, matches tool_use blocks by ID or name, and handles edge cases appropriately.

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[mrubens]

Why do we keep the assistant's tool use?

[mrubens]

Overall this just feels like a lot of special case logic. Is there a way that we could treat it more like a checkpoint rollback following by a new user message and not need any special casing aside from what's already in place to handle that case?