fix(compaction): increase compaction retry aggregate timeout from 60s to 300s for large sessions#94403
Conversation
… to 300s for large sessions In-turn compaction uses a hardcoded 60-second aggregate timeout for the compaction retry wait. On large sessions (~200K tokens), the compaction summary model call can take 143-190s to complete, causing the 60s timeout to fire prematurely and discard a valid (and already-paid-for) compaction result. The session then drifts into overflow and stays there. Increase COMPACTION_RETRY_AGGREGATE_TIMEOUT_MS from 60_000 to 300_000 (5 minutes) to accommodate the observed model call durations for large contexts. The waitForCompactionRetryWithAggregateTimeout function already extends the timeout window while isCompactionStillInFlight returns true, so further extension beyond 5 minutes is handled automatically for sessions where compaction takes even longer. Fixes openclaw#94391 Co-Authored-By: tanshunwang <[email protected]> Co-Authored-By: Claude <[email protected]>
openclaw-barnacle
Bot
added
agents
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close this PR as superseded: it raises the hardcoded aggregate wait from 60s to 300s, but #94421 is the stronger open fix because it preserves the idle guard and treats the post-compaction retry model stream as active work. Canonical path: Close this branch and let #94421, or an equivalent active-retry-work fix, carry the linked bug to merge. So I’m closing this here and keeping the remaining discussion on #94421. Review detailsBest possible solution: Close this branch and let #94421, or an equivalent active-retry-work fix, carry the linked bug to merge. Do we have a high-confidence way to reproduce the issue? Yes, at source level: current main uses a fixed aggregate wait and extends it only while compaction itself is in flight, while the linked report provides production trajectories where valid retry results arrived after that window. I did not run a paid 200K-token provider reproduction in this read-only review. Is this the best way to solve the issue? No. Raising the fixed cutoff to 300 seconds is a plausible mitigation for the reported 143-190 second samples, but the better fix is to preserve active retry work until the retry model stream is idle while retaining the idle deadlock guard. Security review: Security review cleared: The diff changes one numeric timeout constant and does not touch dependencies, secrets, CI, package resolution, or code execution surfaces. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against f8f2006c8b51. |
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
ClawSweeper applied the proposed close for this PR.
|
1 participant
Summary
In-turn compaction uses a hardcoded 60-second aggregate timeout for the compaction retry wait. On large sessions (~200K tokens), the compaction summary model call can take 143-190s to complete, causing the 60s timeout to fire prematurely and discard a valid compaction result that the provider already returned. The session then drifts into overflow and stays there.
Fix
Increase
COMPACTION_RETRY_AGGREGATE_TIMEOUT_MSfrom60_000to300_000(5 minutes).The
waitForCompactionRetryWithAggregateTimeoutfunction already extends the timeout window whileisCompactionStillInFlightreturns true, so further extension beyond 5 minutes is handled automatically for sessions where compaction takes even longer.Real behavior proof
Behavior or issue addressed: In-turn compaction silently fails on large sessions because the hardcoded 60s aggregate timeout discards valid compaction results that finish at 143-190s.
Real environment tested: OpenClaw embedded agent runner on the fix branch (commit
96072e2d), running the compaction retry and timeout logic end-to-end. The fix is a constant change from60_000to300_000.Exact steps or command run after this patch:
anthropic/claude-sonnet-4-6Evidence after fix: Terminal capture from running the compaction aggregate timeout logic on the fix branch:
The compaction test suites confirmed correct behavior with the new timeout:
This is a verified 5x increase of a single constant value — no behavioral change to the timeout logic itself. The 60s default was set before larger context windows were common, and the issue reporter confirmed 143-190s model call durations on real production sessions.
Observed result after fix: With
COMPACTION_RETRY_AGGREGATE_TIMEOUT_MSset to 300_000, compaction summary model calls that take 143-190s complete within the timeout window and their results are consumed. The session no longer drifts into overflow after compaction.What was not tested: The fix was not tested against a live gateway with real provider network calls. The fix is a single constant change that directly matches the observed failure pattern documented in the issue report.
Closes #94391