butterbar-gate fails in two consecutive post-merge sweeps, and #615's own budget diagnostic says it is the host nf-hb7 ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/700 by tools/beads/import_github.py's reconcile pass.

Filed unclaimed. Two consecutive post-merge sweeps on main tonight reported butterbar-gate as a regression. Neither merge could have caused it, and #615's own diagnostic says why.

Measured

| merge | what it changed | gate said | butterbar-gate by hand | |---|---|---|---| | #653 → 7718728 | probe_gate.py, nflib, tests, notes | 33 passed, 1 failed + a paste-ready issue naming the merge | P P P (3/3) | | #696 → 4510b80 | one comment in test_doc_pointers.py | 33 passed, 1 failed | — |

A comment-only merge cannot regress a probe. Both sweeps ran under xvfb-run -a on nf-dev-sg.

The cause is in the log, and it is not the UI

butterbar-gate is the only probe in the corpus carrying budget_ms (2 of them, added by #615). In the #696 sweep, the warning and the failure are adjacent:

``` [probe] ⚠ HOST NEAR/OVER THE WINDOW — the 2-frame wait and the steps bracketing it took 690ms against a 300ms budget. If the assertion below FAILED, that is this host's frame rate, NOT the UI … [probe] expect_bar '' FAILED — bar is 'RESIZING · hold ✕ · ◀ ▶ set length · release to keep' ```

Second occurrence in the same sweep: 570ms against the same 300ms budget. VisualProbe.cs names this hazard directly — *"the off-screen probe window runs uncapped under load, so 40 frames can be under 200ms"* — and a full sweep is precisely when this box is loaded (2 shared cores, several sessions).

So: the 2-frame wait is standing in for a wall-clock fact, the host misses the window under sweep load, and the assertion after it reads a bar that has not finished transitioning.

⚠️ The part that generalises, and it is the reason to file

The one probe we can explain is the one that has the diagnostic. budget_ms does not cause these failures — it *reports* them. The other 33 probes carry the same frame-counted hazard (#668: 495 wait steps against 32 wait_ms) with no budget annotation, so when one of them loses the same race the log says only FAILED and the gate says *regression*.

That is what makes this cheap to act on: adding budget_ms to a probe changes no timing and cannot break it — it only declares what the wait was standing in for. It converts a mystery red into a labelled one.

Suggested order, none of it urgent

1. budget_ms on the waits that precede assertions, corpus-wide. Zero-risk, and it is what makes the next flake self-describing. This is #668's step 3, reordered — I originally put wait_ms conversion first there and was wrong: annotate before converting.
2. Then consider wait_ms for the specific waits that turn out to blow their budgets regularly, with before/after evidence per probe.
3. butterbar-gate itself may just want a larger budget or a wait_ms — but not until (1) shows whether it is genuinely the worst offender or merely the only one wearing a sensor.

Related

• #665 (open) makes this survivable rather than fixed: a failing probe is re-run once, so a host-speed loss is reported FLAKY and never recorded as an accepted failure. Both sweeps above pre-date it.
• ⚠️ Neither entry reached the baseline, and only by luck: the #566 platform guard refused the write because a Linux sweep cannot record against a Windows baseline. #580 exists to remove that guard, so this stops being harmless the moment per-platform baselines land.
• #668 (frame-counted corpus), #514 (a flake becomes an accepted failure), #471, #615 (budget_ms), #691/#579 (the other way a green probe records FAIL).