forked from unom/punktfunk
CI red on `a_worker_that_exits_immediately_is_a_handshake_failure`:
the rung must name the handshake: send Hello: Broken pipe (os error 32)
The test was pinning a premise that is only usually true. `spawn_link` execs a binary
that exits at once, then races it: the parent writes Hello while the child is exiting.
Win the race and the death surfaces as the EOF the recv reads, which carries
`.context("encode worker handshake (died on startup?)")`. Lose it and the peer is
already closed, so the SEND takes EPIPE — and that arm carried only
`.context("send Hello")`, which never contains the word the test looks for.
So this is not merely a test problem. Both arms are one cause — a worker that died
during startup — and the operator was getting two diagnoses for it. On the EPIPE arm the
fallback warn in `open_preferring_worker` degraded to a bare "send Hello: Broken pipe
(os error 32)": it names neither the worker nor the stage that failed, on the one code
path whose entire job is to explain why the session just fell back to the in-process
encoder. The send now names the handshake too, and the race becomes harmless because
both outcomes satisfy the same contract.
The new deterministic rung is the part worth keeping. The spawn-driven test cannot be
trusted to catch this: it did not fail ONCE in 60 runs of the unfixed code in a
container here, because an idle box always wins the race — it is CI's load that loses
it, which is exactly why this reached main. Closing the peer before the handshake starts
reproduces the EPIPE arm with no scheduler dependence at all; backed out, it fails with
CI's exact message.
Verified with CI's own command, `cargo clippy -p pf-encode --all-targets --locked
--features nvenc,vulkan-encode,pyrowave -- -D warnings` + the matching `cargo test`, in
the amd64 container: clippy clean, 123 passed / 0 failed, and 100 consecutive passes of
each of the two rungs. `cargo fmt --all --check` clean. Non-vacuity confirmed by
`Checking pf-encode` / `Compiling pf-encode` in the log.