Problem
bench::tests::distribution_server_reaps_its_fixture_process passes in 0.744s uninstrumented and fails at 30.039s under cargo llvm-cov. The test spawns a fixture process and waits for it to be reaped; instrumentation makes the child roughly forty times slower, and the wait blows a 30-second timeout.
Because coverage runs fail fast, the run then stopped at 18 of 1280 tests, so peryx-ecosystem-oci produced no usable coverage data at all.
Two consequences, and the second is the reason to fix it now.
The failure is misdiagnosed by default. It presents as a broken test, not as instrumentation being too slow. Anyone measuring that crate hits a red run and reasonably concludes the crate is broken — which is what happened, and it cost a measurement pass to work out.
It is latent CI fragility. The workspace coverage job runs on a shared runner. If it ever schedules this test under load, the same timeout applies and the coverage job fails for a reason unrelated to coverage. That has not happened yet, so this is a fix-before-it-bites rather than a report of a current break — but PR #2162 makes the coverage gate load-bearing for every pull request, and a gate that fails for unrelated reasons trains people to rerun rather than investigate.
Required change
Make the test survive instrumentation, or keep it out of instrumented runs.
Raising the timeout is legitimate here and is not the usual paper-over: the timeout is not guarding a race, it is bounding a spawn-and-reap whose child is genuinely forty times slower under instrumentation. If that is the chosen fix, derive the value from a measured instrumented run rather than doubling until it passes, and say in a comment why the number is what it is.
Excluding the test from coverage runs is the other honest option, given it measures process reaping rather than any line worth covering. Say what is given up.
Do not reach for --ignore-run-fail: it is mutually exclusive with --no-fail-fast in cargo-llvm-cov, so it trades one problem for another. A -E 'not test(...)' filter is the working escape hatch if a measurement needs to proceed before this is fixed.
Check whether other spawn-based tests share the shape. A forty-times slowdown is a property of instrumented child processes, not of this test.
Acceptance criteria
- An instrumented run of
peryx-ecosystem-oci completes and produces coverage data.
- If a timeout was raised, its value comes from a measured instrumented run and the reasoning is written down.
- If the test was excluded, what that gives up is stated.
- Other spawn-based tests are checked for the same shape and either fixed together or named as unaffected.
Boundary
The instrumented-run failure and its siblings. Not a change to what the test asserts, and not a change to the coverage gate itself.
Problem
bench::tests::distribution_server_reaps_its_fixture_processpasses in 0.744s uninstrumented and fails at 30.039s undercargo llvm-cov. The test spawns a fixture process and waits for it to be reaped; instrumentation makes the child roughly forty times slower, and the wait blows a 30-second timeout.Because coverage runs fail fast, the run then stopped at 18 of 1280 tests, so
peryx-ecosystem-ociproduced no usable coverage data at all.Two consequences, and the second is the reason to fix it now.
The failure is misdiagnosed by default. It presents as a broken test, not as instrumentation being too slow. Anyone measuring that crate hits a red run and reasonably concludes the crate is broken — which is what happened, and it cost a measurement pass to work out.
It is latent CI fragility. The workspace coverage job runs on a shared runner. If it ever schedules this test under load, the same timeout applies and the coverage job fails for a reason unrelated to coverage. That has not happened yet, so this is a fix-before-it-bites rather than a report of a current break — but PR #2162 makes the coverage gate load-bearing for every pull request, and a gate that fails for unrelated reasons trains people to rerun rather than investigate.
Required change
Make the test survive instrumentation, or keep it out of instrumented runs.
Raising the timeout is legitimate here and is not the usual paper-over: the timeout is not guarding a race, it is bounding a spawn-and-reap whose child is genuinely forty times slower under instrumentation. If that is the chosen fix, derive the value from a measured instrumented run rather than doubling until it passes, and say in a comment why the number is what it is.
Excluding the test from coverage runs is the other honest option, given it measures process reaping rather than any line worth covering. Say what is given up.
Do not reach for
--ignore-run-fail: it is mutually exclusive with--no-fail-fastin cargo-llvm-cov, so it trades one problem for another. A-E 'not test(...)'filter is the working escape hatch if a measurement needs to proceed before this is fixed.Check whether other spawn-based tests share the shape. A forty-times slowdown is a property of instrumented child processes, not of this test.
Acceptance criteria
peryx-ecosystem-ocicompletes and produces coverage data.Boundary
The instrumented-run failure and its siblings. Not a change to what the test asserts, and not a change to the coverage gate itself.