fix(test): deflake ensure_warm parallel-promote timing assertion - #562
Merged
Conversation
ensure_warm_for_dispatch_promotes_in_parallel asserted both loader.peak() >= 2 (deterministic: concurrent loads observed) and elapsed < 1.5x delay (a wall-clock proxy). The wall-clock bound flaked on cold/contended CI runners (notably Windows, where the nightly-2026-07-14 cache miss plus blocking-pool ramp-up pushed even a correct parallel run past 150ms), which ejected release PR #560 from the merge queue. The peak-in-flight counter already proves the parallelism contract with no timing race: a serial re-promote loop never exceeds peak 1. Drop the redundant wall-clock assertion and rely on the deterministic signal.
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
index::tests::ensure_warm::ensure_warm_for_dispatch_promotes_in_parallelflaked on the Windows merge-queue runner and ejected release PR #560 from the queue (panic atensure_warm.rs:328).The test made two parallelism assertions:
loader.peak() >= 2— deterministic: theSlowBodyLoaderrecords peak concurrent in-flightload()calls; a parallel fan-out sees ≥ 2, a serial loop sees 1.elapsed < 1.5 × delay(150 ms) — a wall-clock proxy.On a cold/contended runner (the nightly-2026-07-14 cache miss + tokio blocking-pool ramp-up), assertion 2 blew its bound even when the fan-out ran correctly in parallel — a timing race, not a real regression.
Fix
Drop the redundant wall-clock assertion; keep the deterministic peak-in-flight counter, which already pins the parallelism contract (a serial re-promote loop can never exceed peak 1). No production code changed — test-only.
Verified locally:
cargo nextest run -p uffs-daemon ensure_warm_for_dispatch_promotes_in_parallel→ passes (0.13s).