dbsp: keep the compaction test below the level-0 merge trigger - #6760
Merged
Conversation
`test_is_compaction_complete` fed 30 transactions and then asserted that some spine still held more than one batch, so that the compaction request it makes next has real merging to do. That assertion raced the background merger. Level 0 starts a merge once 8 loose batches accumulate and then takes every loose batch, and each 500-record transaction adds one level-0 batch per spine, so 30 transactions leave the spine exactly one batch past the trigger at 29. When the merger task wakes late enough for batch 30 to arrive first, the sweep absorbs all nine batches and the spine collapses to a single one, and the test fails with `expected at least one spine with >1 batch before compaction, got [1, 1]`. It hit 2 of the last 200 merge-queue runs, both on arm64, where 20 libtest threads oversubscribe the runner. Feed one batch fewer than the trigger instead. A spine below `MIN_LEVEL0_MERGE_BATCHES` merges nothing on its own, so all seven batches wait for the explicit compaction request and the pre-condition holds by construction. Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>
mihaibudiu
approved these changes
Jul 29, 2026
ryzhyk
enabled auto-merge
July 29, 2026 23:13
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
3 participants
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.
Fixes the
test_is_compaction_completeflake that failed the merge queue in run 30493031729 (PR #6756, docs-only, unrelated to the failure):Root cause
The test fed 30 transactions and then asserted that some spine still held more than one batch, so that the compaction request it makes next has real merging to do. That assertion raced the background merger.
Level 0 starts a merge once 8 loose batches accumulate and then takes every loose batch (
MERGE_COUNTS[0]=8..=128), and each 500-record transaction adds exactly one level-0 batch per spine (250 records per worker, far belowMAX_LEVEL0_BATCH_SIZE_RECORDS= 14,999). So the steady-state batch count per spine is a pure function of the transaction count:30 sits exactly one batch past the merge trigger at 29, so the test's whole margin was a single input batch: when the level-0 merger task wakes late enough for batch 30 to arrive before it grabs the loose set, the sweep absorbs all nine batches and the spine collapses to one. It hit 2 of the last 200 merge-queue runs, both on arm64, where 20 libtest threads oversubscribe the runner.
No product bug: collapsing a spine to a single batch is the merge policy doing its job.
Fix
Feed one batch fewer than the trigger. A spine below
MIN_LEVEL0_MERGE_BATCHESmerges nothing on its own, so all seven batches wait for the explicit compaction request and the pre-condition holds by construction rather than by luck. The level-0 minimum gets a name so the test depends on the constant instead of restating 8.Describe Manual Test Plan
Release build,
aarch64-apple-darwin,crates/dbsplib tests:[7, 7]every run[7, 7]every runSharedState::is_compaction_completehardcoded totrueexpected all spines to have <=1 batch after compaction, got [7, 7]spineandtrace::test subsets (117 tests)cargo fmt --check -p dbspThe negative control matters here: when the old test collapsed to
[1, 1], its post-condition passed trivially, which is what the pre-check was guarding against. For reference, the old test produced[9, 9]idle and scattered across[2, 2],[9, 4],[30, 30]under load.Checklist
Breaking Changes?
None.
🤖 Generated with Claude Code