https://docs.all-hands.dev/ logo
Join Slack
Powered by
Hey <@U080DD1FR4K>! I’m encountering some issues w...
# proj-agent
l
Hey @wide-doctor-37830! I’m encountering some issues when a conversation crashes mid tool call, openhands analysis of related issues in the thread. Are you working on resolving this still?
1. #1782 - Duplicate ObservationEvent with same tool_call_id causes LLM API error on conversation resume Status: Open | Created: Jan 21, 2026 This is the closest match to your issue. It describes: Duplicate 
ObservationEvent
created with same 
tool_call_id
after conversation resume • Results in: 
"tool_use" ids were found without "tool_result" blocks
Puts conversation in unrecoverable state • Suggested fix: Add deduplication in 
filter_unmatched_tool_calls()
2. #2127 - Conversation Error: Missing tool_result block for tool_use Status: Open | Created: Feb 19, 2026 (yesterday!) This describes: Terminal action executed but ObservationEvent wasn’t recorded until 87 minutes later Causes tool_use without corresponding tool_result to be sent to API • Similar error: 
messages.16: tool_use ids were found without tool_result blocks
3. #1841 - send_message() during pending tool execution corrupts message history Status: Open | Created: Jan 27, 2026 This describes: User messages sent while tool is executing corrupts message ordering Results in: 
[tool_use] → [user message] → [tool_result]
instead of 
[tool_use] → [tool_result] → [user message]
• Proposed fix: Reorder in 
events_to_messages()
or queue messages
w
Not explicitly. I spent a few days working on this PR this week, which refactors views to make it easier to ensure messages are well-formed. But one thing that PR assumes is that events are well-formed when they come into the system. These issues sound like events are coming in out of order or not at all and we don't robustly handle those cases anywhere
nod 1
I saw this PR draft of yours, which looks like it attempts to resolve these issues by validating messages right before they're sent to the LLM. It might be helpful if this kind of validation check is pushed as early as possible, all the way up to the conversation state and event log.
If events truly are dropped or duplicated, they'll go all the way through the view manipulations and condenser system before that validation kicks in and I don't think they'll handle those cases very well.
I'll make some time to poke around these issues today though, see if there are some quick wins
l
Yeah, my PR draft was motivated by this! I think that if we can validate earlier it could help a lot
c
FWIW I suspect the user message can arrive between an action and an observation, and it seems that is a valid thing that can happen
l
I think basically what is happening is that the runtime crashes following a tool call, and the tool call is added to the event stream, but not the tool result
c
In some cases, yes... In other cases the observation was added, but late, after a user message
Open in Slack
PreviousNext
Powered by