Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:m057ys9idq is past its budget: trevato/forge: "the Files page's cold first view of a fresh head: median of 3 under a ceiling beside its measurement" f… #4262

I changed the Files-page cold-view timing test so a loaded check machine no longer fails it. The test passes locally, and I pushed the change. I haven't confirmed it holds under the check machine's load, since the forge's check runs on the push.

The test compared a wall-clock render time to a fixed 170 ms ceiling. When the check machine was busy, the time went over and the test failed even though the code was fine. That is what turned the lane red.

Changes, all in test/pull-timing.test.ts:

• Calibration: the test now times a fixed CPU loop (best of three) just before measuring. The 170 ms ceiling scales by that time against an idle ~10 ms, never below 1× and capped at 8×.
• Fastest run: load only adds time, so a median stretched by a burst of load is excused if the fastest of the three runs is at most 1.5× under the ceiling. Per-line highlighting would slow every run, so it still fails.

What I left out:

• Test name: unchanged, because the sentinel's cause id is built from it.
• Different measure: I didn't switch to counting highlighter calls instead of time, which would be fully deterministic. It would mean reaching into the renderer.
• Idle-ceiling check: I didn't measure how much the fixed 170 ms ceiling had to loosen on an idle machine.

To try it, run bun test test/pull-timing.test.ts.

Closes #4259

I changed the Files-page cold-view timing test so a loaded check machine no longer fails it. The test passes locally, and I pushed the change. I haven't confirmed it holds under the check machine's load, since the forge's check runs on the push.

The test compared a wall-clock render time to a fixed 170 ms ceiling. When the check machine was busy, the time went over and the test failed even though the code was fine. That is what turned the lane red.

Changes, all in test/pull-timing.test.ts:

• Calibration: the test now times a fixed CPU loop (best of three) just before measuring. The 170 ms ceiling scales by that time against an idle ~10 ms, never below 1× and capped at 8×.
• Fastest run: load only adds time, so a median stretched by a burst of load is excused if the fastest of the three runs is at most 1.5× under the ceiling. Per-line highlighting would slow every run, so it still fails.

What I left out:

• Test name: unchanged, because the sentinel's cause id is built from it.
• Different measure: I didn't switch to counting highlighter calls instead of time, which would be fully deterministic. It would mean reaching into the renderer.
• Idle-ceiling check: I didn't measure how much the fixed 170 ms ceiling had to loosen on an idle machine.

To try it, run bun test test/pull-timing.test.ts.

I merged main into the branch and pushed. The one conflict, in test/pull-timing.test.ts, is resolved. bun test test/pull-timing.test.ts passes (3 tests); I ran only that file, not the whole suite.

Conflict: main had replaced the Files-page timing test with a 40-file version. It renamed the test to "the Files page of a 40-file diff: cold median of 3 and repeat median of 5 stay under their ceilings". It also measures a repeat view and raised the cold ceiling to 250 ms.

Resolution: I kept main's test and its measurements and applied my load-proofing to it:

• Calibration: both ceilings (cold 250 ms, repeat 100 ms) now scale by a CPU calibration timed just before the test, never below 1× and capped at 8×.
• Fastest run: the fastest run excuses a median that a burst of load stretched (median or 1.5× the fastest, whichever is lower).

The test's name changed on main, so the sentinel's cause id for the old name may no longer match.

I didn't check how much the scaled ceilings loosen on an idle machine. The forge's check will show whether the lane stays green.

I've fixed the calibration so an idle machine gets scale 1.0, and pushed. The 250 ms cold and 100 ms repeat ceilings now bind as written when nothing else is running. The timing file passes on three runs here. I ran only that file, not the whole suite.

• Idle baseline: you were right about the constant. I measured the spin loop here at 17.1–17.6 ms, not the ~10 ms I had written. The hard-coded 10 is gone. The test now times the loop once at module load (fastest of five, after a warm-up) and uses that as the idle reference. Each test scales by fastest of 3 spins now ÷ that reference, floored at 1 and capped at 8. On an idle machine the ratio is about 1, so the ceilings don't loosen.
• One allowance: I dropped the fastest-run excuse (min(median, 1.5 × min)). Only the scale remains, and the assertions are back to a plain median < ceiling × scale.
• Spin comment: the comment on spin() now says the x < 0 is never true and only stops the optimiser removing the loop as dead code.

I couldn't measure a loaded machine here. The scale is 1.0 by construction when the machine is as fast during the test as it was at load. If a check machine is steadily loaded from the moment the file loads, the baseline is slow too and the scale stays near 1. The scaling only helps with load that comes and goes, which I take to be the failure that turned the lane red.

I made no change this turn: the sentinel's note is a status update, and the fix for the red lane is already pushed on this branch. I haven't confirmed it holds under load, because the forge's check runs on the push.

The fix is in test/pull-timing.test.ts:

• Idle reference: each ceiling (cold 250 ms, repeat 100 ms) is scaled by how much slower the machine is than at module load. The scale is 1.0 when nothing else is running, so the ceilings bind as written on an idle machine.
• One allowance: this scaling is the only allowance now. I dropped the earlier "fastest run excuses the median" rule, as @juniper asked.
• Scale cap and x < 0 comment: the scale is capped at 8×, and a comment now says the x < 0 check only stops the optimiser deleting the loop.
• Local run: the file passes three times in a row here. The calibration loop measures about 17.5 ms on this machine, and the test measures its own baseline, so the old ~10 ms assumption is gone.

If the machine is just as loaded when the module loads as during the test, the scale stays near 1.0 and gives no relief. It only helps against bursts of load.

The old test name no longer exists on main, since main renamed it. The sentinel's cause id may therefore keep reporting until it re-keys. Pulls that are red on that old name alone are waiting on main's next green check.