From 3c39354833d524f056e840475751b8a1e9efa1ab Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sun, 20 Sep 2026 18:46:58 +0700 Subject: [PATCH] Measure the Wire.Closed flake rather than assume it It exits 1 with no FAIL line, which is the shape an earlier lane wrote up. Two-of-two early failures looked like they might be this lane's, so: 4 in 6 here against 2 in 6 on a detached worktree at this branch's own base commit, running test_dev alone. Noise at that sample size, same exception, same mechanism. Adds one detail to the earlier note, which had only ever seen the flake on dev-trap-null-alloc: one of my six landed on dev-trap-free-all instead, so what is racy is trap_park and every row that calls it. --- FIX.org | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/FIX.org b/FIX.org index 09c4c91..8cf9138 100644 --- a/FIX.org +++ b/FIX.org @@ -1767,5 +1767,20 @@ expectation on purpose and watching all three report. Seventeen checker rows in ~test_flan.ml~: four accepting (both ~dead-beef~ arities and a computed pattern among them), and thirteen refusals covering the boundary, both arities, both no-expected-type positions, the byte's range, the pattern's -range and the ~defconst~ rule. Per the sweep policy the ~@x86~ and +range and the ~defconst~ rule. + +~dune test~ exits 1 on this branch roughly half the time, with *no FAIL line +anywhere* — the ~Flan.Wire.Closed~ flake an earlier lane wrote up further up +this file. Measured rather than assumed, because 2-of-2 early failures looked +like mine: running ~test_dev.exe~ alone (15 seconds, not the ten-minute +suite) gives 4 failures in 6 on this branch and *2 in 6 on a detached +worktree at this branch's own base commit*, 1526b6f, with none of this lane +in it. Same exception, same mechanism, and the difference is noise at that +sample size. + +One detail worth adding to that earlier writeup, which said both observed +failures landed on ~dev-trap-null-alloc~: it is not row-specific. Five of my +six failures were that row and the sixth was ~dev-trap-free-all~, so what is +racy is ~trap_park~ itself and every row that calls it, which is what the +mechanism described there would predict. Per the sweep policy the ~@x86~ and ~@sanitize~ sweeps were not run here.