Bug: Condensation summary can be inserted between action and observation, breaking LLM API message ordering

[peter-zhong-replit]

Disclaimer: LLM Generated Content Contained Herein. I verified it before posting.

Summary

After condensation, the CondensationSummaryEvent can be inserted at a position that breaks action-observation pairs or splits parallel tool call batches. This causes LLM API errors because the message ordering requirements are violated.

Problem

The LLMSummarizingCondenser uses a fixed summary_offset equal to keep_first when creating a Condensation event. However, after View.from_events() applies filtering (via _enforce_batch_atomicity and filter_unmatched_tool_calls), the actual kept_events list structure may differ from the original.

This causes the summary to be inserted at an unsafe position:

1. Between an ActionEvent and its matching ObservationEvent - The LLM API expects tool results to immediately follow the assistant's tool call
2. Between two ActionEvents from the same parallel batch - Parallel tool calls must be grouped in a single assistant message

Observed Behavior

Debug output showing the bug:

[DEBUG] Events BEFORE summary insertion:
  [0] SystemPromptEvent
  [1] MessageEvent
  [2] ObservationEvent [tool_call_id=toolu_01TL...]  ← orphaned from previous condensation
  [3] ActionEvent [tool_call_id=toolu_01Vk...]
  [4] ObservationEvent [tool_call_id=toolu_01Vk...] --> INSERT HERE (offset=4)
  ...
[DEBUG] ⚠️  WARNING: Inserting BETWEEN action and observation!
         Action at [3] with tool_call_id=toolu_01Vk...
         Observation at [4] with tool_call_id=toolu_01Vk...

After insertion, the event order becomes:

ActionEvent → CondensationSummaryEvent → ObservationEvent

When converted to LLM messages:

assistant (tool_call) → user (summary) → tool (result)

This violates Anthropic's API requirement that tool results must immediately follow the assistant's tool_use block.

Impact

• LLM API errors due to malformed message sequences
• Conversation state corruption after condensation
• Intermittent failures (only occurs when summary_offset happens to land at an unsafe position)

Root Cause

View.from_events() inserts the summary at the offset stored in the Condensation event without verifying the position is safe after filtering has modified the event list structure.

See: https://openhands-ai.slack.com/archives/C06U8UTKSAD/p1765744162377229

[enyst]

Cc: @csmith49 may know what's up here?

[csmith49]

Thanks @peter-zhong-replit for the investigation. Can you also share your agent configuration when you're observing this issue? It would be helpful to know the condenser config and tool setup, especially if either are non-standard.

Here's my hypothesis for why we're seeing this now: the keep_first=4 parameterization was chosen for the v0 agent, where we were guaranteed to have the same four events starting the history (system message, user message, recall action, recall observation). The condenser would always forget events after this prefix and insert the summary as the next event. So maybe it's not surprising that with new agent setups this implicit structure is broken and could introduce bugs.

If this is correct then an easy way to resolve the issue is to set keep_first=2.

That's not a robust fix, of course. Peter's suggested fix from Slack would probably stop the bugs, but I'd much prefer the summary be inserted where it says it will be, which means we need to update the condenser logic to pick an insertion point that won't break things. I think there's a natural way to extend a recent PR of mine (#1380) to handle that logic and will investigate ASAP.

One question on this example though:

[DEBUG] Events BEFORE summary insertion:
  [0] SystemPromptEvent
  [1] MessageEvent
  [2] ObservationEvent [tool_call_id=toolu_01TL...]  ← orphaned from previous condensation
  [3] ActionEvent [tool_call_id=toolu_01Vk...]
  [4] ObservationEvent [tool_call_id=toolu_01Vk...] --> INSERT HERE (offset=4)
  ...
[DEBUG] ⚠️  WARNING: Inserting BETWEEN action and observation!
         Action at [3] with tool_call_id=toolu_01Vk...
         Observation at [4] with tool_call_id=toolu_01Vk...

The observation event at index 2 is orphaned -- but how does that happen? It should be removed by the filter_unmatched_tool_calls. Is this a real debug situation or just an example?

[peter-zhong-replit]

Can confirm keep_first was set at 4. For the example I think that's a debug situation, I bleieve it was actually inserted at an event little further down the stream

[csmith49]

Possible fix for this issue in PR #1412. Still testing the changes.

[csmith49]

Marking this closed now that #1412 is merged. Summaries can now only be inserted between action/observation pairs. Also see #1508 for a related problem and fix.