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
- Start with a session that is genuinely over the compaction threshold.
- Let auto memory-flush compaction run.
- End compaction without a trustworthy
tokensAfter snapshot being persisted into the session store.
- 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
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
/statusdisplay issue. It affects the actual compaction gate.User-visible symptoms
In our repro on a Telegram thread session:
compactionCountincreasedThe session looked like it was compacting successfully, but the gate still behaved as if the old oversized prompt were active.
Repro shape
tokensAftersnapshot being persisted into the session store.Observed:
Expected:
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 exampletotalTokens=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:
Compactionskeeps increasing even during ordinary chat)Suggested fix
Treat post-compaction token state as an invariant:
tokensAfter, persist it immediately