Skip to content

fix(memory): resolve memoryFlush 0/0 guard blocking flush on never-flushed sessions (#47143)#83015

Open
Bartok9 wants to merge 1 commit into
openclaw:mainfrom
Bartok9:fix/47143-memory-flush-zero-compaction-guard
Open

fix(memory): resolve memoryFlush 0/0 guard blocking flush on never-flushed sessions (#47143)#83015
Bartok9 wants to merge 1 commit into
openclaw:mainfrom
Bartok9:fix/47143-memory-flush-zero-compaction-guard

Conversation

@Bartok9

@Bartok9 Bartok9 commented May 17, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #47143memoryFlush never triggers for sessions where both compactionCount and memoryFlushCompactionCount are 0 but no flush has actually run.

Root cause

hasAlreadyFlushedForCurrentCompaction uses a simple equality guard:

return typeof lastFlushAt === 'number' && lastFlushAt === compactionCount;

When both values are 0 this produces a false positive — the session is treated as already flushed even if memoryFlushAt has never been set. This blocks every memory flush for sessions in this state.

The ambiguity arises because 0 can mean either:

  1. Legacy / never-flushed row — field was written as 0 by an older code path or defaulted before the column existed
  2. Real cycle-0 flush — a flush ran before the first compaction and correctly stored memoryFlushCompactionCount: 0

Fix

Require memoryFlushAt to be present when both counters are 0 before treating the row as already flushed:

// When the compaction counter is 0 on both sides, the match is ambiguous.
// Require an explicit memoryFlushAt timestamp to confirm a real flush ran.
if (compactionCount === 0 && !entry.memoryFlushAt) {
  return false;
}

Why this is safe:

  • Fresh sessions always clear memoryFlushAt at creation (session.ts:717) — they will never be falsely gated
  • Sessions where a real cycle-0 flush ran will have memoryFlushAt set — once-per-cycle deduplication is preserved for them
  • Sessions with compactionCount > 0 are unaffected — the equality guard alone is unambiguous for those

Changes

  • src/auto-reply/reply/memory-flush.ts — add memoryFlushAt to the Pick<> type and the zero-counter guard
  • src/auto-reply/reply/reply-state.test.ts — update the existing 0/0 test to pass memoryFlushAt (correctly represents real cycle-0 flush), add two new cases for legacy/never-flushed rows

Test verification

✅ non-zero match with memoryFlushAt → true
✅ counts differ → false
✅ memoryFlushCompactionCount undefined → false
✅ 0/0 with memoryFlushAt (real cycle-0 flush) → true
✅ 0/0 no memoryFlushAt (legacy bug case) → false
✅ 0/0 memoryFlushAt:undefined → false

Acceptance criteria from ClawSweeper review:

  • node scripts/run-vitest.mjs src/auto-reply/reply/reply-state.test.ts src/auto-reply/reply/agent-runner-memory.test.ts
  • pnpm exec oxfmt --check --threads=1 src/auto-reply/reply/memory-flush.ts src/auto-reply/reply/reply-state.test.ts ✅ passes

Real behavior proof

Behavior or issue addressed: memoryFlush 0/0 guard incorrectly blocks flushes on legacy/never-flushed sessions (issue #47143). Fix in src/auto-reply/reply/memory-flush.ts requires explicit memoryFlushAt before treating a 0/0 row as already flushed.

Real environment tested:

  • Date: 2026-05-27T21:42:39Z
  • Host: Darwin 25.4.0 arm64 (macOS, Apple Silicon)
  • Node: v25.5.0
  • Branch: fix/47143-memory-flush-zero-compaction-guard @ 30f7153eec8

Exact steps or command run after this patch:

node scripts/run-vitest.mjs run src/auto-reply/reply/reply-state.test.ts --reporter=verbose

Evidence after fix:

 RUN  v4.1.7 /Users/bartokmoltbot/clawd/openclaw

 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > hasAlreadyFlushedForCurrentCompaction > returns true when memoryFlushCompactionCount matches compactionCount 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > hasAlreadyFlushedForCurrentCompaction > returns false when memoryFlushCompactionCount differs 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > hasAlreadyFlushedForCurrentCompaction > returns false when memoryFlushCompactionCount is undefined 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > hasAlreadyFlushedForCurrentCompaction > treats missing compactionCount as 0 when memoryFlushAt confirms a real flush 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > hasAlreadyFlushedForCurrentCompaction > returns false for persisted 0/0 rows with no memoryFlushAt (legacy / never-flushed) 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > hasAlreadyFlushedForCurrentCompaction > returns false for 0/0 row where memoryFlushAt is explicitly undefined 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > shouldRunMemoryFlush > skips when already flushed for current compaction count 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > shouldRunMemoryFlush > runs when above threshold and not flushed 0ms
 ✓ auto-reply  src/auto-reply/reply/reply-state.test.ts > shouldRunMemoryFlush > runs on consecutive compaction cycles when flush records the pre-increment count 0ms
 (... 33 additional passing tests in same file omitted for brevity ...)

 Test Files  1 passed (1)
      Tests  42 passed (42)
   Start at  17:42:29
   Duration  4.18s (transform 2.84s, setup 244ms, import 3.81s, tests 40ms, environment 0ms)

Process exited with code 0.

Observed result after fix:

All 42 tests in reply-state.test.ts pass, including the six hasAlreadyFlushedForCurrentCompaction cases that exercise the new guard. Critically, the two new legacy-row cases ("returns false for persisted 0/0 rows with no memoryFlushAt" and "returns false for 0/0 row where memoryFlushAt is explicitly undefined") both pass — these would have returned true before the patch (false positive that blocked all flushes on never-flushed sessions). The cycle-0 real-flush case ("treats missing compactionCount as 0 when memoryFlushAt confirms a real flush") still correctly returns true, preserving once-per-cycle deduplication.

What was not tested:

  • The companion agent-runner-memory.test.ts file referenced in the original ClawSweeper acceptance criteria — only reply-state.test.ts was rerun for this proof. The PR's logic change is fully covered by the file rerun above.
  • End-to-end behavior of a real session compacting and then flushing memory (integration-level); this PR is a unit-level guard fix and the targeted unit tests are the appropriate level of verification.

Update 2026-06-13 — rebased onto current main

Rebased onto upstream/main @ 340c2456bb (single commit 2ca229fe32, Bartok9 authorship preserved) to re-trigger fresh CI and clear the stale late-May failures. The rebase was clean (no conflicts); memoryFlushAt already exists on SessionEntry in current main (src/config/sessions/types.ts:385), so the guard change applies directly.

Re-verified on the rebased branch (real output):

  • node scripts/run-vitest.mjs run src/auto-reply/reply/reply-state.test.ts42/42 passed
  • oxlint on the two touched source files → 0 warnings, 0 errors
  • check-changelog-attributions → exit 0

Direct function-level repro of the 0/0 guard (calls hasAlreadyFlushedForCurrentCompaction directly, real output):

alreadyFlushed=false  | Never-flushed session (0/0, no memoryFlushAt) — must allow flush
alreadyFlushed=true   | Real flush ran in cycle 0 (0/0 + memoryFlushAt set) — already flushed
alreadyFlushed=true   | Counters match at cycle 2 (real flush) — already flushed
alreadyFlushed=false  | Counter advanced past last flush — allow flush

Line 1 is the bug this PR fixes: before the change, a never-flushed session with the ambiguous 0/0 counter state returned true (flush silently blocked forever); now it returns false so the flush proceeds. Line 2 confirms a session that genuinely flushed in cycle 0 (memoryFlushAt set) is still correctly treated as already-flushed — no double-flush regression.

@openclaw-barnacle openclaw-barnacle Bot added size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 17, 2026
@clawsweeper

clawsweeper Bot commented May 17, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed July 1, 2026, 12:21 AM ET / 04:21 UTC.

Summary
The PR changes the memory-flush compaction dedupe guard to require memoryFlushAt before treating ambiguous 0/0 rows as already flushed, with focused helper tests and a changelog entry.

PR surface: Source +21, Tests +26, Docs +1. Total +48 across 3 files.

Reproducibility: yes. at source level: current main's helper returns true for a numeric 0 matching the defaulted compaction count of 0, and runMemoryFlushIfNeeded uses that helper to skip memoryFlush. I did not run a live over-threshold session in this read-only review.

Review metrics: 1 noteworthy metric.

  • Persisted memory-flush interpretation: 1 guard path changed. The PR changes when a stored 0/0 memory-flush counter pair is treated as already flushed, which is the compatibility-sensitive review surface.

Stored data model
Persistent data-model change detected: serialized state: src/auto-reply/reply/reply-state.test.ts, unknown-data-model-change: src/auto-reply/reply/memory-flush.ts, vector/embedding metadata: src/auto-reply/reply/memory-flush.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #47143
Summary: This PR is the active candidate fix for the canonical 0/0 memoryFlush guard bug; older same-fix PRs are closed unmerged, and nearby memoryFlush work covers adjacent trigger or counter lifecycle failures.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦞 diamond lobster
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • [P1] Add redacted terminal/log proof, copied live output, or a short recording from a real over-threshold session showing memoryFlush proceeds after the patch.
  • Remove the CHANGELOG.md entry and keep the release-note context in the PR body or squash message.

Proof guidance:

  • [P1] Needs stronger real behavior proof before merge: The PR body supplies terminal unit-test and direct-helper output, but not redacted logs, live output, or a recording from a real over-threshold OpenClaw session reaching memoryFlush after the patch. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

  • [P1] The PR changes how persisted 0/0 memory-flush metadata is interpreted, so maintainers should be comfortable that real cycle-0 flush and exhausted-flush records always carry memoryFlushAt.
  • [P1] The supplied proof is terminal unit/direct-helper output, not a real over-threshold OpenClaw session showing memoryFlush proceeding after the patch.

Maintainer options:

  1. Require real session proof and cleanup (recommended)
    Before merge, ask for redacted live output, logs, or a short recording from an over-threshold session showing the 0/0 row reaches memoryFlush, and drop the release-owned changelog line.
  2. Accept source-level proof intentionally
    Maintainers may choose to accept the helper tests and source trace for this narrow guard if they are comfortable owning the session-state upgrade risk.
  3. Pause for broader memoryFlush semantics
    If maintainers want to handle the adjacent pre-request and context-budget reports together, pause this PR and keep the linked issue as the canonical bug.

Next step before merge

  • [P1] Manual review/contributor action is needed because the remaining blockers are real behavior proof, maintainer comfort with the session-state interpretation, and a release-owned changelog edit, not a repair ClawSweeper can prove for the contributor.

Security
Cleared: The diff touches source, tests, and changelog only, with no dependency, workflow, credential, package, or executable supply-chain changes.

Review findings

  • [P3] Remove the release-owned changelog entry — CHANGELOG.md:5937
Review details

Best possible solution:

Land the narrow memoryFlushAt discriminator after real over-threshold session proof and removal of the release-owned changelog entry, while tracking adjacent context-budget and pre-request failures separately.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: current main's helper returns true for a numeric 0 matching the defaulted compaction count of 0, and runMemoryFlushIfNeeded uses that helper to skip memoryFlush. I did not run a live over-threshold session in this read-only review.

Is this the best way to solve the issue?

Yes, with proof and cleanup caveats: memoryFlushAt is the narrow existing discriminator for real recorded cycle-0 flushes versus legacy or never-flushed 0/0 rows. A broader sentinel or migration rewrite would be more invasive for this specific bug.

Full review comments:

  • [P3] Remove the release-owned changelog entry — CHANGELOG.md:5937
    CHANGELOG.md is release-generated and release-owned for normal PRs. Please drop this line and keep the release-note context in the PR body or squash message so release generation owns the final entry.
    Confidence: 0.95

Overall correctness: patch is correct
Overall confidence: 0.87

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 5a5913a98b03.

Label changes

Label justifications:

  • P2: This is a source-backed session memory-flush correctness bug with real but bounded impact.
  • merge-risk: 🚨 session-state: The PR changes how persisted session memory-flush metadata is interpreted for dedupe and upgrade behavior.
  • rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦞 diamond lobster.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body supplies terminal unit-test and direct-helper output, but not redacted logs, live output, or a recording from a real over-threshold OpenClaw session reaching memoryFlush after the patch. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed

PR surface:

Source +21, Tests +26, Docs +1. Total +48 across 3 files.

View PR surface stats
Area Files Added Removed Net
Source 1 24 3 +21
Tests 1 27 1 +26
Docs 1 1 0 +1
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 3 52 4 +48

What I checked:

  • Repository policy read: Root AGENTS.md was read fully; no scoped AGENTS.md owns src/auto-reply/reply, and the root review policy marks session-state behavior and changelog edits as review-relevant. (AGENTS.md:1, 5a5913a98b03)
  • Current main guard still has the bug: hasAlreadyFlushedForCurrentCompaction defaults missing compactionCount to 0 and returns true when numeric memoryFlushCompactionCount equals it, so a persisted 0/0 row is still treated as already flushed on main. (src/auto-reply/reply/memory-flush.ts:185, 5a5913a98b03)
  • Runtime caller uses the guard to skip flushing: runMemoryFlushIfNeeded routes token-threshold flushing through shouldRunMemoryFlush and the transcript-size branch through hasAlreadyFlushedForCurrentCompaction, so the helper controls whether memoryFlush proceeds. (src/auto-reply/reply/agent-runner-memory.ts:1250, 5a5913a98b03)
  • Existing state writes support memoryFlushAt as discriminator: Fresh sessions clear both flush markers, while successful and exhausted flush paths persist memoryFlushAt with the compaction-count marker, making it the narrow existing discriminator for real recorded flushes. (src/auto-reply/reply/session.ts:859, 5a5913a98b03)
  • Current tests encode the false-positive state: The current helper test still expects { memoryFlushCompactionCount: 0 } with missing compactionCount to return true, which is the source-level reproduction of the linked bug. (src/auto-reply/reply/reply-state.test.ts:431, 5a5913a98b03)
  • Latest release is not fixed: v2026.6.11 still contains the same equality-only helper and the same test expectation, so the bug is not already shipped as fixed. (src/auto-reply/reply/memory-flush.ts:185, e085fa1a3ffd)

Likely related people:

What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

@clawsweeper clawsweeper Bot added P2 Normal backlog priority with limited blast radius. impact:session-state Session, memory, transcript, context, or agent state can drift or corrupt. labels May 17, 2026
@Bartok9
Bartok9 force-pushed the fix/47143-memory-flush-zero-compaction-guard branch from 6b89e48 to 30f7153 Compare May 27, 2026 21:24
@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. and removed impact:session-state Session, memory, transcript, context, or agent state can drift or corrupt. labels May 27, 2026
@clawsweeper

clawsweeper Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?
  • The egg game starts only after the PR passes the real-behavior proof check.
  • Before that, no creature or rarity is rolled. The treat waits for real proof.
  • This is still just collectible flavor: proof affects review readiness, not creature quality.

@Bartok9

Bartok9 commented May 27, 2026

Copy link
Copy Markdown
Contributor Author

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

@openclaw-barnacle openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 27, 2026
@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. labels May 27, 2026
…ushed sessions

hasAlreadyFlushedForCurrentCompaction incorrectly returns true when both
compactionCount and memoryFlushCompactionCount are 0, preventing the memory
flush from running on sessions that have grown past the token threshold but
have never actually been flushed.

Root cause: the equality guard (lastFlushAt === compactionCount) produces a
false positive when both sides are 0 — this state is ambiguous between:
  1. A legacy / never-flushed row whose field was written as 0 (or defaulted)
  2. A real cycle-0 flush (compacted, then flushed before any second compaction)

Fix: require memoryFlushAt to be present when compactionCount === 0 before
treating the 0/0 row as already flushed.  Fresh sessions always clear
memoryFlushAt on creation, so they will never be falsely gated.  Sessions
where a real cycle-0 flush ran will have memoryFlushAt set and continue to
be deduped correctly.

Expand the Pick<> in both the helper signature and shouldRunMemoryFlush
entry type to include memoryFlushAt.  Update tests: the existing
'treats missing compactionCount as 0' case now also passes memoryFlushAt to
represent a real cycle-0 flush, and two new cases verify the legacy 0/0
path returns false.

Fixes openclaw#47143
@Bartok9
Bartok9 force-pushed the fix/47143-memory-flush-zero-compaction-guard branch from 30f7153 to 2ca229f Compare June 14, 2026 01:46
@clawsweeper clawsweeper Bot added merge-risk: 🚨 session-state 🚨 May lose, corrupt, stale, or mis-associate session, agent, or context state. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. labels Jun 18, 2026
@clawsweeper

clawsweeper Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

@Bartok9 thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward.

Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive.

Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it.

@Bartok9

Bartok9 commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Thanks @clawsweeper — real behavior proof is already present and the repo's own "Real behavior proof" CI check is passing on the current head (green in the checks list above), alongside the full test suite and security gates.

Recap of the proof already in the PR body:

  • node scripts/run-vitest.mjs run src/auto-reply/reply/reply-state.test.ts42/42 passed, including the two new legacy 0/0/no-memoryFlushAt cases (return false after the fix; would have returned true before) and the cycle-0 real-flush case (still true, no double-flush regression).
  • Direct function-level repro calling hasAlreadyFlushedForCurrentCompaction:
    alreadyFlushed=false  | Never-flushed session (0/0, no memoryFlushAt) — must allow flush
    alreadyFlushed=true   | Real flush ran in cycle 0 (0/0 + memoryFlushAt set) — already flushed
    alreadyFlushed=true   | Counters match at cycle 2 (real flush) — already flushed
    alreadyFlushed=false  | Counter advanced past last flush — allow flush
    

Line 1 is exactly the reported bug: a never-flushed 0/0 session no longer has its flush silently blocked forever. Rebased clean onto current main; memoryFlushAt already exists on SessionEntry.

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

@clawsweeper

clawsweeper Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix(memory): resolve memoryFlush 0/0 guard blocking flush on never-flushed sessions (#47143) This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-risk: 🚨 session-state 🚨 May lose, corrupt, stale, or mis-associate session, agent, or context state. P2 Normal backlog priority with limited blast radius. proof: supplied External PR includes structured after-fix real behavior proof. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. size: S status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

memoryFlush never triggers when compactionCount and memoryFlushCompactionCount are both 0

1 participant