Hmbown/CodeWhale · error

Compaction failed after {MAX_RETRIES} retries

Error message

Compaction failed after {MAX_RETRIES} retries

What it means

compact_messages_safe retries transient failures (network, rate limit, timeout - never context overflow, which needs the smaller-input ladder) MAX_RETRIES=3 times with 1s/2s/4s backoff. This error (crates/tui/src/compaction.rs:977) means every attempt failed; the original message history is never corrupted - the function returns Err instead.

Source

Thrown at crates/tui/src/compaction.rs:977

                drop(removed);
                return Ok(CompactionResult {
                    messages: sanitize_retained_messages(msgs),
                    summary_prompt: prompt,
                    retries_used: attempt.saturating_add(quality_retries),
                });
            }
            Err(e) => {
                // Only retry on transient errors
                if !is_transient_error(&e) {
                    return Err(e);
                }
                last_error = Some(e);
            }
        }
    }

    Err(last_error
        .unwrap_or_else(|| anyhow::anyhow!("Compaction failed after {MAX_RETRIES} retries")))
}

fn build_compaction_summary_block_text(summary: &str, anchors: &str) -> String {
    let summary = summary.trim();
    let summary = if summary.is_empty() {
        "(no summary available)"
    } else {
        summary
    };
    let mut text = format!("{SUMMARY_HEADER}\n\n{summary}");
    text.push_str(anchors);
    text
}

/// Codex-parity replacement history: the most recent plain user messages,
/// selected newest-first within a fixed token budget and restored to
/// transcript order. The oldest selected message is truncated to fit rather
/// than dropped whole.

View on GitHub (pinned to 8880682c63)

Solutions

1. Wait 30-60s and trigger compaction again - session history is intact
2. Check the quota/rate-limit dashboard for the active key
3. Verify basic reachability of the provider endpoint (curl) before retrying
4. If it persists, point compaction at a different model or provider temporarily
5. If the last error is genuinely absent from the message, look for upstream logs - the fallback arm fires only when the loop exited without capturing one

fn is_compaction_retry_exhausted(msg: &str) -> bool {
    msg.contains("Compaction failed after") && msg.contains("retries")
}

// The library already did 3 retries with 1s/2s/4s backoff; add a slower outer tier
match compact_now().await {
    Err(e) if is_compaction_retry_exhausted(&e.to_string()) => {
        tokio::time::sleep(Duration::from_secs(60)).await;
        compact_now().await // history is intact, retry is safe
    }
    r => r,
}

When it happens

Trigger: Sustained 429 rate limiting across the whole ~7s retry window; network down or DNS failing for the full window; provider outage where each summarization attempt times out.

Common situations: Free-tier keys hitting org-wide limits; laptop sleep/resume mid-compaction; provider incidents; a proxy that resets long request durations.

Related errors

• failed to fetch {description} from {url}: HTTP {status} {bod
• Could not inspect GitHub Release ${tag}: ${detail}
• DeepSeek ${res.status}: ${text}
• Runtime API request failed (${status}): ${message}
• Runtime API request failed (${status}): ${message}

AI-assisted analysis of Hmbown/CodeWhale@8880682c63 (2026-08-16). Data as JSON: /api/errors/f28a7c3689b2eb33. Report an issue: GitHub.