Greptile Summary

This PR fixes a bug where memoryFlush would fire on every other auto-compaction cycle instead of every cycle. The root cause was that memoryFlushCompactionCount was being overwritten with the post-increment compaction count, making the hasAlreadyFlushedForCurrentCompaction dedup check falsely return true on the next invocation and skip the flush. The fix is correct: keeping memoryFlushCompactionCount at the pre-increment value restores the intended dedup semantics, and the primary token-threshold gate still prevents spurious repeated flushes within the same cycle.

Confidence Score: 5/5

Safe to merge — targeted, well-documented bug fix with passing tests.

The change is a two-line deletion and one-line no-op (void nextCount) in a clearly understood code path, backed by an explanatory comment and a corrected test expectation. The logic is sound: using the pre-increment compaction count preserves dedup within a cycle while allowing the flush to fire on each new compaction cycle. No P0/P1 findings.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(memory): preserve pre-increment comp..." | Re-trigger Greptile}

Related work from PRtags group charming-crane-ftmo

Title: Open PR duplicate: memoryFlush compaction counter skip

* This PR

Closing this as duplicate or superseded after Codex automated review.

PR #69138 is a focused and plausible fix, but it duplicates the same remaining memoryFlush compaction-counter work already tracked by older open PR #51421 and bug #12590. Current main still has the implicated post-increment assignment, so this is not implemented; the best cleanup is to close this duplicate and keep review concentrated on #51421.

Best possible solution:

Close #69138 as a duplicate and keep the remaining review and landing discussion on older open PR #51421, with #12590 as the user-facing bug report. When landing the canonical fix, preserve the pre-increment counter behavior and include regression coverage that proves memoryFlush can run on consecutive compaction cycles.

What I checked:

• Current main still has the post-increment assignment: On current main d54d2d6, runMemoryFlushIfNeeded initializes memoryFlushCompactionCount from the active compaction count, then after memoryDeps.incrementCompactionCount returns nextCount, assigns memoryFlushCompactionCount = nextCount. (src/auto-reply/reply/agent-runner-memory.ts:800, d54d2d6b9b8a)
• Dedup gate makes equal counters significant: shouldRunMemoryFlush returns false when hasAlreadyFlushedForCurrentCompaction is true; that helper returns true exactly when memoryFlushCompactionCount equals compactionCount. (src/auto-reply/reply/memory-flush.ts:80, d54d2d6b9b8a)
• Current test still reflects old behavior: The colocated runner test still expects persisted memoryFlushCompactionCount to be 2 after compaction, while PR fix(memory): preserve pre-increment compaction count in memoryFlushCompactionCount (#12590) #69138 changes that expected value to the pre-increment count 1. (src/auto-reply/reply/agent-runner-memory.test.ts:168, d54d2d6b9b8a)
• Older canonical PR remains open for the same fix: GitHub API shows PR fix(memory): memoryFlush fires every compaction cycle instead of every other #51421 is open, was created before fix(memory): preserve pre-increment compaction count in memoryFlushCompactionCount (#12590) #69138, fixes the same every-other memoryFlush behavior, and removes the same post-increment reassignment in src/auto-reply/reply/agent-runner-memory.ts. Its file diff changes const nextCount/assignment into an await-only increment and preserves the pre-increment memoryFlushCompactionCount. (src/auto-reply/reply/agent-runner-memory.ts:800, 9732faa51779)
• Discussion already identified the duplicate group: The PRtags comment on fix(memory): preserve pre-increment compaction count in memoryFlushCompactionCount (#12590) #69138 groups fix(memory): memoryFlush fires every compaction cycle instead of every other #51421 and fix(memory): preserve pre-increment compaction count in memoryFlushCompactionCount (#12590) #69138 under 'Open PR duplicate: memoryFlush compaction counter skip'. The Greptile comment also validates fix(memory): preserve pre-increment compaction count in memoryFlushCompactionCount (#12590) #69138's root-cause analysis, which is useful but does not make this newer PR the canonical tracking item.
• No protected close blockers: Issue API shows fix(memory): preserve pre-increment compaction count in memoryFlushCompactionCount (#12590) #69138 is open, authored by a CONTRIBUTOR, and only has the size: XS label; it does not have security, beta-blocker, release-blocker, or maintainer labels.

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against d54d2d6b9b8a.