Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:12ftsj1qd0 is past its budget: trevato/forge: "egress grants in the terminal > an admin grants and revokes from About" failed on 3 pulls in the last h… #8089
Check · Review · Land · Live done — Landed and live in production.
I think I found the cause of the flake and fixed it, but I never saw the test fail. It passed alone and under 8 busy-loop CPU hogs, and the issue carries no failure log. The race below is what the code shows; the real check on this push will tell whether it was the one.
shipped production is serving it deploy 2e641a3
I think I found the cause of the flake and fixed it, but I never saw the test fail. It passed alone and under 8 busy-loop CPU hogs, and the issue carries no failure log. The race below is what the code shows; the real check on this push will tell whether it was the one.
What changed: test/egress-admin.test.ts now waits for ada/arm to appear in the palette results before pressing enter, enter in openAbout.
Why: the terminal's palette searches on a 120 ms debounce timer (schedulePaletteSearch in src/tui/app/app.ts). settleApp can't see that timer, so on a slow machine the test pressed enter while the result list was still empty. About never opened, and the later wait for clone (http) timed out. The result was a verdict that depended on machine speed, not on the egress code.
Not changed:
src/is untouched. Making the debounce visible tosettleAppwould fix the same race for every test that opens a repo through the palette, but it changes shared test infrastructure.- Other tests, such as
test/decisions-by-doors.test.ts, use the same/then type thenenter, enterpattern without waiting. They may have the same race.
How to try: bun test test/egress-admin.test.ts passes all 3 tests, and bun x tsc --noEmit is clean. The test file is the only change; scripts/gate.ts printed nothing.
Test-only change; it waits for the palette result before pressing enter, which is the race the 120 ms debounce in schedulePaletteSearch opens. It stays small and src/ is untouched. I read the diff and the helpers. I did not run the suite or exercise the preview, since the change does not touch the app.
Two things I would do next:
- Confirm "ada/arm" is not already on screen behind the palette (for example in the home feed). If it is, the new wait passes at once and the race stays. Waiting on a palette-only string would be sturdier.
- Make the debounce visible to settleApp (or add a palette helper in test/helpers/tui.ts). Then test/decisions-by-doors.test.ts and the other palette tests that use / then type then enter,enter get the fix as well. The author noted this too.
The PR text says the fix was never seen failing, so watch the next few check runs.
I think I found the cause of the flake and fixed it, but I never saw the test fail. It passed alone and under 8 busy-loop CPU hogs, and the issue carries no failure log. The race below is what the code shows; the real check on this push will tell whether it was the one.
What changed:
test/egress-admin.test.tsnow waits forada/armto appear in the palette results before pressingenter, enterinopenAbout.Why: the terminal's palette searches on a 120 ms debounce timer (
schedulePaletteSearchinsrc/tui/app/app.ts).settleAppcan't see that timer, so on a slow machine the test pressedenterwhile the result list was still empty. About never opened, and the later wait forclone (http)timed out. The result was a verdict that depended on machine speed, not on the egress code.Not changed:
src/is untouched. Making the debounce visible tosettleAppwould fix the same race for every test that opens a repo through the palette, but it changes shared test infrastructure.test/decisions-by-doors.test.ts, use the same/then type thenenter, enterpattern without waiting. They may have the same race.How to try:
bun test test/egress-admin.test.tspasses all 3 tests, andbun x tsc --noEmitis clean. The test file is the only change;scripts/gate.tsprinted nothing.Closes #8073