Residual from #42204
After a real compaction, applyCompactionResult replaces the history with the summary plus the compactor's stripped tail and then resets the injection ledgers through resetInjectionLedgersForStrip. The memory-v3 section store's clearConversation is fail-soft: when the memory database rejects the delete, it logs and reports false, and the reset reports incomplete. On the non-compacting path the dispatcher keeps the injected history in that case, so residency and history agree. On the compacted path there is no injected history to keep: the frozen bodies are already gone from the summary output while the store still classifies their sections as resident, so a later re-selection emits a <memory_pointer> line with no body behind it until the next successful reset (the next compaction, or /clean).
This is the pre-existing best-effort behavior of the clear (the store has always swallowed its own failure); #42204 made the outcome observable but did not change the compacted path.
Options
- Retry the store clear once with a short backoff before continuing (covers
SQLITE_BUSY).
- Or, when the clear fails, hand the injector a per-conversation "ledger unreliable" flag so it renders every selection afresh (no pointers) until a clear succeeds.
- Or, treat the clear as part of the durable compaction commit and re-throw so the turn aborts, accepting that a memory-database fault then fails the turn.
Related: #42204 (see the Codex thread "Handle failed ledger clears after real compaction").
Residual from #42204
After a real compaction,
applyCompactionResultreplaces the history with the summary plus the compactor's stripped tail and then resets the injection ledgers throughresetInjectionLedgersForStrip. The memory-v3 section store'sclearConversationis fail-soft: when the memory database rejects the delete, it logs and reportsfalse, and the reset reports incomplete. On the non-compacting path the dispatcher keeps the injected history in that case, so residency and history agree. On the compacted path there is no injected history to keep: the frozen bodies are already gone from the summary output while the store still classifies their sections as resident, so a later re-selection emits a<memory_pointer>line with no body behind it until the next successful reset (the next compaction, or/clean).This is the pre-existing best-effort behavior of the clear (the store has always swallowed its own failure); #42204 made the outcome observable but did not change the compacted path.
Options
SQLITE_BUSY).Related: #42204 (see the Codex thread "Handle failed ledger clears after real compaction").