openclaw - 💡(How to fix) Fix compaction can immediately re-enter on stale totals when no trustworthy post-compaction snapshot is persisted [1 participants]

Summary

After auto memory-flush compaction, the next turn can immediately re-enter compaction if the session store does not persist a trustworthy post-compaction token snapshot or explicitly invalidate stale totals.

This is not just a /status display issue. It affects the actual compaction gate.

User-visible symptoms

In our repro on a Telegram thread session:

• a turn triggered auto memory-flush compaction
• compactionCount increased
• the next normal message immediately triggered another compaction again
• this could repeat even though the live prompt had already been reduced

The session looked like it was compacting successfully, but the gate still behaved as if the old oversized prompt were active.

Repro shape

1. Start with a session that is genuinely over the compaction threshold.
2. Let auto memory-flush compaction run.
3. End compaction without a trustworthy tokensAfter snapshot being persisted into the session store.
4. Send the next normal user turn.

Observed:

• the next turn can immediately re-enter compaction based on stale totals / fallback estimates from before compaction

Expected:

• after compaction, the session should either:
  • persist a trustworthy post-compaction prompt/context snapshot, or
  • explicitly invalidate the old snapshot so the next turn does not reuse stale totals as fresh truth

Why this seems to happen

The compaction lifecycle updates compactionCount, but there are cases where the session store still ends up with effectively stale token state (for example totalTokens=null, totalTokensFresh=false, or an old larger snapshot still being preferred).

Once that happens, the next turn can re-enter compaction even though the prompt was already reduced.

Why this matters

This can cause:

• repeated unnecessary compactions
• confusing operator state (Compactions keeps increasing even during ordinary chat)
• degraded continuity because the session keeps being compacted more often than intended

Suggested fix

Treat post-compaction token state as an invariant:

• if compaction can produce a trustworthy tokensAfter, persist it immediately
• otherwise explicitly invalidate stale totals before the next turn
• the next-turn compaction gate should never treat a pre-compaction snapshot as fresh after compaction has already completed