From 0b4bf850ec8f85c9c1ccb02817146e5d6507444b Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sun, 20 Sep 2026 15:47:06 +0700 Subject: [PATCH] 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. --- FIX.org | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/FIX.org b/FIX.org index 5b8cb1b..58df760 100644 --- a/FIX.org +++ b/FIX.org @@ -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.