The random exit 1 is test_dev's trap rows, and it predates this lane

dune test exits 1 roughly two runs in five with no FAIL line anywhere:
test_dev's trap_park polls a daemon that has just aborted at the break
loop, using a bare Wire.send/Wire.recv pair, and a daemon that exits
between the two raises Wire.Closed with nothing to catch it. The binary
dies and every row after it is skipped.

Measured on a detached worktree at dev-loop's tip with none of this lane
in it: 2 of 5 runs, same exception, same row. Same rate as this branch,
because it is the same code. Written down rather than patched -- the fix
is a claim about what those rows mean when the program ends under them,
which belongs to whoever owns them.
This commit is contained in:
Joseph Ferano 2026-09-20 15:47:06 +07:00
parent bd29eee3e4
commit 0b4bf850ec

23
FIX.org
View File

@ -1575,3 +1575,26 @@ by hand rather than trusted to the auto-merge. Three acceptance rows for
diff of the program's real output across the same three, captured by hand
before the rows were written and again after the rebase. It is in
~test_sanitize.ml~'s list; per the sweep policy the sweep itself was not run.
** Found while running it: ~dune test~ exits 1 at random, and has since before
this lane
~test_dev.ml~'s ~trap_park~ rows are racy, and when they lose the race the
whole test binary dies with ~Fatal error: exception Flan.Wire.Closed~ — exit
1 with no FAIL line anywhere, which is the worst shape a failure can have
given that the sweep policy says a lane is judged on the exit status.
The mechanism: ~trap_park~ polls with ~ask~, which is a bare ~Wire.send~ /
~Wire.recv~ pair with nothing around it, and the program it is polling has
just aborted at the break loop. If the daemon exits between the send and the
recv, ~Wire.recv~ raises ~Closed~, nothing catches it, and every row after it
— in this lane's case the new class daemon among them — never runs. Both
observed failures landed at the same row, ~dev-trap-null-alloc~.
*It is not this lane's.* Measured on a detached worktree at dev-loop's tip
(c4e0725) with nothing of this lane in it: 2 of 5 runs exit 1 with the same
exception at the same row, against 2 of 5 on this branch. The rates match
because the code is the same.
Not fixed here, deliberately: the fix is to catch ~Closed~ in that poll and
read it as the program having ended, which is a claim about what those rows
mean and belongs to whoever owns them. Flagged rather than patched.