JosephFerano/flan
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Measure the Wire.Closed flake rather than assume it

Browse Source 
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.
This commit is contained in:
Joseph Ferano 2026-09-20 18:46:58 +07:00
parent 7bd2c99353
commit 3c39354833
1 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
FIX.org
View File

@ -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 in ~test_flan.ml~: four accepting (both ~dead-beef~ arities and a computed
pattern among them), and thirteen refusals covering the boundary, both pattern among them), and thirteen refusals covering the boundary, both
arities, both no-expected-type positions, the byte's range, the pattern's 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. ~@sanitize~ sweeps were not run here.