← Back to PRs

#12760: fix(memory-flush): fire on every compaction cycle instead of skipping alternate cycles (#12590)

by lailoo open 2026-02-09 16:31 View on GitHub →
stale size: XS trusted-contributor
## Summary Fixes #12590 ## Problem `memoryFlush` only fires on every **other** auto-compaction cycle. After a flush where compaction also completes, `incrementCompactionCount` bumps `compactionCount` from N to N+1, and the code assigns this new value to `memoryFlushCompactionCount` — synchronizing both counters. On the next cycle, `shouldRunMemoryFlush` sees them equal and skips the flush. ## Fix Stop overwriting `memoryFlushCompactionCount` with the post-increment value. The flush records the **pre-increment** `compactionCount`, so the next compaction cycle sees `compactionCount > memoryFlushCompactionCount` and correctly triggers the flush. Change: 3 lines removed (the `nextCount` reassignment), `let` to `const`. ## Reproduction and Verification ### Before fix (main branch) — Bug reproduced: ``` PASS Cycle 1: first flush (compactionCount=1, no prior flush): got=true FAIL Cycle 2: after flush+compaction (compactionCount=2, memoryFlushCompactionCount=2): got=false, expected=true PASS Cycle 3: next compaction (compactionCount=3, memoryFlushCompactionCount=2): got=true FAIL Cycle 4: after flush+compaction again (compactionCount=4, memoryFlushCompactionCount=4): got=false, expected=true BUG CONFIRMED: memoryFlush skips cycles where counters are synchronized ``` ### After fix — All verified: ``` PASS Cycle 1: first flush triggers PASS Cycle 2: flush triggers (compactionCount=2, flushCount=1) PASS Cycle 3: flush triggers (compactionCount=3, flushCount=2) PASS Cycle 4: flush triggers (compactionCount=4, flushCount=3) PASS Dedup: same compactionCount, already flushed PASS Under threshold: low tokens PASS No entry: undefined All checks passed ``` ## Effect on User Experience **Before fix:** Users with `memoryFlush` enabled see memories saved only on ~50% of compaction cycles. Important context is silently lost. **After fix:** `memoryFlush` fires reliably on every compaction cycle. ## Testing - 11 unit tests pass (`memory-flush.test.ts`) - 8 integration tests pass (`agent-runner.memory-flush.*.test.ts`) - Lint passes <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change fixes a regression where `memoryFlush` was only firing every other auto-compaction cycle. In `src/auto-reply/reply/agent-runner-memory.ts`, the flush now records `memoryFlushCompactionCount` using the *pre-increment* `compactionCount` and no longer overwrites it with the post-increment value returned by `incrementCompactionCount`, which previously synchronized the counters and caused the next cycle to be skipped. Tests were updated to reflect the intended behavior by asserting `memoryFlushCompactionCount` remains at the pre-increment value even when `compactionCount` is incremented after a flush, and a new unit test was added to confirm `shouldRunMemoryFlush` triggers across successive compaction counts. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - The change is small and directly addresses the described counter-sync bug; it aligns with how `incrementCompactionCount` persists only the compaction increment while `memoryFlushCompactionCount` is persisted separately. Updated tests lock in the intended pre-increment recording behavior and cover the regression scenario at the unit and integration level. - No files require special attention <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs