Adopt a nextest release that fixes the capture leak

[gaborbernat]

Problem

LEAK and LEAK-FAIL reports appear intermittently across this workspace's test suites. #1629 identified the cause: a race in nextest between pipe() and set_cloexec(), tracked upstream as nextest-rs/nextest#3553, which is still open.

The identification is complete and the reading is documented in contributing/ci.md. Nothing in this repository can fix it — peryx does not own the descriptor and holds nothing to close. Every proposed local remedy hides the report rather than changing what it reports: raising the timeout, excluding a test, retrying, or serialising.

So the remedy is an upgrade, and this issue exists so that upgrade is tracked rather than remembered.

Required change

Adopt a nextest release that contains the fix for nextest-rs/nextest#3553, once one exists.

At the time of filing, 0.9.143 is the newest release and does not contain it. Check the upstream issue and nextest's changelog before assuming a newer version helps — a version bump that does not include the fix is churn, and worse, it would invite the conclusion that the problem is solved when the reports continue.

When a release does contain it, bump the pinned version and confirm the reports stop. That confirmation matters: the reports are intermittent, roughly one event per few hundred spawns, so a single green run proves nothing. Run enough to be confident, and say how many.

Then remove the workaround guidance from contributing/ci.md and the corresponding rule from the lane brief, so the next person does not keep waving off a report that no longer has a benign explanation.

Acceptance criteria

• The pinned nextest version contains the fix for 🐛 fix(runner): stop concurrent spawns inheriting capture pipes nextest-rs/nextest#3553, verified against upstream rather than assumed from the version number.
• Enough runs to distinguish a fix from luck, with the count stated.
• contributing/ci.md no longer tells readers to expect and ignore these reports.
• If a LEAK still appears after the upgrade, it is treated as a new defect rather than folded back into the old explanation.

Boundary

A dependency upgrade and the documentation it obsoletes. Not a change to any test, not a timeout adjustment, and not a local workaround. If no fixed release exists yet, this issue simply waits — do not close it by working around the problem.

[gaborbernat]

Checked upstream before assuming a version bump helps, and there is nothing to adopt yet.

The newest cargo-nextest release is still 0.9.143, published 2026-08-04, which is the version this repository already resolves to and the one this issue records as lacking the fix. No release has shipped since. Upstream nextest-rs/nextest#3553 is still open, last updated 2026-09-07.

It still reproduces on 0.9.143. Two consecutive full runs of peryx-ha-distributed gave 1701 passed both times, the second reporting (1 leaky) on control::tests::test_the_idempotency_window_evicts_the_oldest_receipt. A peryx-ecosystem-pypi coverage run earlier the same day reported (2 leaky).

Per the criterion about not folding a real defect back into the old explanation, I checked whether that test leaks a handle of its own. It does not: it builds a scripted control double and a fixed clock, makes four in-memory execute calls and asserts a length. It opens no file, no socket and no subprocess, so it holds no descriptor it could leak. The report can only be a capture pipe inherited from a concurrent spawn, which is the upstream race rather than anything this repository owns.

So this waits, as the boundary says. No version bump, no workaround, and contributing/ci.md keeps its guidance until a release actually carries the fix.

[gaborbernat]

Third leak observation, recorded here because it is the same class and this is the open issue for it.

peryx-test-support::test_a_restart_sweeps_the_blob_stages_a_killed_process_left_behind reported LEAK in a 5-test concurrent run and was clean in isolation.

The lane that saw it established what it is not: its change adds no pipe and no spawn, and the file descriptor it retains is CLOEXEC, so no child inherits it. So this is not a handle the test holds past its body.

That makes three observations of the same shape, none of which is a test holding its own descriptor:

test	crate	conditions
test_the_idempotency_window_evicts_the_oldest_receipt	ha-distributed	entirely in-memory — opens no file, socket or subprocess
benchmark_cli_exposes_oci_options	oci	single timing event at 1313/1314; not reproducible — see #2221
test_a_restart_sweeps_the_blob_stages_a_killed_process_left_behind	test-support	concurrent run only, clean alone, retained fd is CLOEXEC

All three appear only under contention and none can be explained by the test's own descriptors. That is the signature of an inherited capture pipe from a concurrent spawn — nextest#3553 — rather than three separate defects.

Nothing to adopt yet: nextest is still 0.9.143 and #3553 is open upstream. Recording these so the next observation is recognised as a fourth instance rather than investigated from scratch.

For anyone reproducing: #2221 established that the default profile's 100ms leak window is where these appear, and --profile ci's 1s window is ten times more tolerant — so the coverage job is the least likely place to see one, not the most.