Condenser crashes with 'Cannot condense 0 events' when tool loop spans view

[neubig]

Problem

The LLMSummarizingCondenser.get_condensation() raises NoCondensationAvailableException with message 'Cannot condense 0 events' when a tool loop spans almost the entire view, leaving no valid range for forgetting events.

When this happens with a HARD condensation requirement, the hard_context_reset() is called but may also fail or return None, causing the exception to bubble up and crash the conversation.

Root Cause Analysis

In _get_forgotten_events():

1. forgetting_start is calculated as the smallest manipulation index >= keep_first
2. forgetting_end is calculated as the smallest manipulation index >= naive_end
3. When a tool loop spans most of the view, these can be equal
4. view[forgetting_start:forgetting_end] returns an empty list
5. This triggers the 'Cannot condense 0 events' exception

Reproduction

This occurs in production when:

• A conversation has many events
• A tool loop (atomic unit) spans most of the recent events
• The condenser is triggered with a HARD requirement

Proposed Fix Options

1. Graceful degradation: Instead of crashing, return the view uncondensed and log a warning
2. Adjust boundaries: When forgetting_start == forgetting_end, try to find an earlier manipulation index
3. Hard reset improvement: Make hard_context_reset() more robust to handle edge cases

References

• Linear ticket: ALL-5012
• DataDog error query: environment:production status:error "Cannot condense 0 events."
• Example conversation: 1423d3a3-1999-4221-b85d-046246fcee2b

[enyst]

I think maybe we could remove keep_first or at least ignore it in the case of full condensation. We know, in the current SDK codebase, we need only system prompt and user message. 🤔

(and the summary will (try to) highlight the other user messages)

I think the assumption that it’s useful is getting a bit outdated now, it was before Opus 4.5 (of course) and even, it was at a time when many LLMs didn’t work or barely worked with tool use. Idk, is there any known real-world benefit at this time? 🤷‍♂️

[csmith49]

I think maybe we could remove keep_first or at least ignore it in the case of full condensation.

I believe we already do ignore it when we trigger the hard context reset. We could experiment with removing it entirely (by setting the default keep_first to 0), but I'm skeptical it would address the problems in this issue. If you want to try it out in your configs LMK how it goes.

[csmith49]

Digging into the proposed solutions here a bit to think out loud:

Graceful degradation: Instead of crashing, return the view uncondensed and log a warning

I think this was the approach taken in #2259? The problem is usually that the hard condensation request comes when there's a context window exception from the completion endpoint, so returning the original view will just trigger the condensation again and get us stuck in a loop.

Adjust boundaries: When forgetting_start == forgetting_end, try to find an earlier manipulation index

This is similar to Engel's suggestion of removing keep_first. We'd want to push forgetting_start as early as possible, but at least with our default values this means we get rid of the first user message and possibly the system prompt. Our early condenser experiments suggested these were pretty important to maintain to keep the agent on-track, but that may not be true anymore.

Hard reset improvement: Make hard_context_reset() more robust to handle edge cases

Absolutely a reasonable approach. In my testing I've never seen the hard context reset fail, but I'll dig through the logs to see if I can identify any explanations.

[csmith49]

Digging into the logs I found a few rare instances where the hard context reset was failing. They all seem to be due to the same error:

Hard context reset summarization failed with exception: litellm.BadRequestError: OpenrouterException - {"error":{"message":"This endpoint's maximum context length is 200000 tokens. However, you requested about 200648 tokens (648 of text input, 200000 in the output). Please reduce the length of either one, or use the \"middle-out\" transform to compress your prompt automatically.","code":400,"metadata":{"provider_name":null}}}. Reducing max event size to 192 and retrying.

So the hard context reset is getting stuck in a loop where it's trying to shrink events smaller and smaller but the endpoint keeps complaining that we're using too much context.

[csmith49]

Potential fix in #2264.

[all-hands-bot]

[Automatic Post]: This issue has been waiting for triage. @xingyaoww @neubig @enyst, could you please take a look and add the appropriate priority label when you have a chance?

[all-hands-bot]

[Automatic Post]: This issue has been waiting for triage. @xingyaoww @neubig @enyst, could you please take a look and add the appropriate priority label when you have a chance?