open-standards/proof/proof-rs/crates/proof-cascade
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 44df0fa6cb proof-cascade's sleep-versus-compute test kills the busy children it started if a later one fails to start
tests/process_energy.rs starts four busy children (`while :; do :; done`) to burn CPU beside a
metered sleep, collecting them as they spawn. If one failed to start, its `expect` panicked
with the ones before it already spinning, and those were dropped as bare std::process::Child
values, which are not killed when they are dropped: they spun on after the test binary had
ended. Each child is now held, as it is spawned, in a `Running` that kills it and reaps it,
waiting up to 10 s, when it is dropped (as wai-quantum-service's tests hold theirs,
04d19cfd8), so a panic part way through the collect ends those already running; at the end the
test drops them where it killed and waited for each.

Planted fault, on the old-prod Mac Studio (macOS, M3 Ultra, where the process counter is the
meter and this branch runs): the third spawn made to panic, with two children running, the
test run alone in a session and process group of its own (POSIX setsid through perl), and the
group listed 3 s after cargo ended. At main it held both children (/bin/sh -c while :; do :;
done), then killed by their group; with the guard it held nothing.

Gates, on the old-prod Mac Studio: cargo test --locked -p proof-cascade passed (128 tests in
9 binaries), leaving nothing in its process group; cargo clippy --locked --all-targets
--no-deps -p proof-cascade -- -D warnings is clean. The light checks pass.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-10 12:35:59 -05:00
..
src The public IOReport status variants say what they mean under the 3-tick cap 2026-11-07 08:30:52 -05:00
tests proof-cascade's sleep-versus-compute test kills the busy children it started if a later one fails to start 2026-11-10 12:35:59 -05:00
Cargo.toml Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00