TestTheDay2ReaderControlFindsABrokenComparator fails intermittently on unchanged main

[vde-dis]

TestTheDay2ReaderControlFindsABrokenComparator (tools/conformance) fails intermittently at 3f1e404, with a message that blames the comparator. The cause looks like SIGPIPE on a printf pipe, not the comparator.

What we traced, at 3f1e404:

• The harness runs set -uo pipefail (day2_test.go:40). The second runDay2 call defines d2_says() { ok "$1: stubbed"; } (day2_test.go:111), which never reads stdin. d2_reader_control pipes printf into it (day2lib.sh:76-77, 79, 82).
• If the function exits before printf has written, printf is killed by SIGPIPE (status 141) and pipefail makes the pipeline non-zero. The payloads are 62 and 36 bytes, so the pipe buffer plays no part. The first call (day2_test.go:107) uses the real d2_says, which reads stdin through jq (day2lib.sh:38), so it is not exposed.
• The visible result is day2_test.go:114 failing, with FAIL: the read-back comparator cannot find a planted value or ... passed an absent path.

What we measured, on a shared 2-CPU machine, so read the numbers as orders of magnitude:

• The compiled test, 150 runs with two yes >/dev/null & loops running: 74 failed. With cat >/dev/null; added to that stub: 0 of 150.
• The same printf | d2_says shape in a plain bash loop under the same load: 4418 of 5000 printf exits were non-zero, and every one of them was 141.
• CI, main, since the test was added (2026-09-04): the Go workflow ran 62 times on push and this test failed twice, both in Test on macos-15: run 34114050733 (2026-09-07, "cannot find a planted value") and run 34945505039 (2026-09-15, "passed an absent path").

#708 already noted the symptom ("Load-dependent"); this only adds the mechanism and the rates. We found no issue or discussion about it. Our open #806 mentions it in one sentence.

To see it:

git clone https://github.com/stephrobert/feint && cd feint && git checkout 3f1e404
yes >/dev/null & yes >/dev/null &
go test ./tools/conformance -run '^TestTheDay2ReaderControlFindsABrokenComparator$' -count=150
kill %1 %2

Not checked: the bash on the macOS runners (the macOS cause is inferred from the identical messages and the identical file); other tests in tools/conformance for the same shape (a grep of inline stubs found only this one, but we did not read them all); how tools/falsify treats a flaky baseline for a-day-2-leg.json, which names this test.

A suggestion, in case it helps: in day2_test.go:111, d2_says() { cat >/dev/null; ok "$1: stubbed"; }. The stub still passes everything and pipefail stays on. Nothing in the tree says the unread stub is deliberate; if it is, we would like to know. We can send this as a pull request in whichever shape you prefer.

Drafted with Claude Code assistance.