Repository navigation
test(mem_wal): make snapshot freeze coverage deterministic - #10549
Merged
Merged
Conversation
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.
Tip: disable this comment in your organization's Code Review settings.
BubbleCal
approved these changes
Nov 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
test_memory_snapshot_never_drifts_from_writer_state::case_2_zero_grace_evicts_on_commitcan fail at its coverage precondition even when a memtable freeze occurred. The test used the currentfrozen_bytesorfrozen_countas evidence of a past freeze. With zero grace, a successful flush retires the frozen handle immediately, so both values can legitimately be zero after the freeze.This was observed in the main
linux-buildjob (run 41262655601). The drift andunflushed_bytesassertions did not fail; this change does not claim that production snapshot drift or memory corruption occurred.Fix
Capture the initial active memtable generation and assert that it advanced after the existing 24 puts. Generation only advances when the active memtable is rotated, so it proves the freeze path ran without depending on a transient frozen handle.
After the existing flush drain:
frozen_count == 0;frozen_count > 0;frozen_bytes == 0accounting and everyassert_no_drift/unflushed_bytesinvariant remain unchanged.The change is test-only.
Validation
2 passed.test_memtable_stats_frozen_count_outlives_frozen_bytes,test_frozen_retained_during_grace_then_swept, andtest_frozen_evicted_immediately_with_zero_grace: passed.fmt,typos): passed.frozen_bytes=0,frozen_count=0, and generation1 -> 3. This demonstrates the false event inference but is not an unchanged-timing reproduction and is not part of the patch.linux-buildpassed all 18,764 tests, including both cases oftest_memory_snapshot_never_drifts_from_writer_state. All applicable workflows completed successfully; the path-filtered Arrow ordering compatibility job was skipped as expected.