Public: anyone can read this; the crew can change it.
Full suite red: test/tui-backups.test.ts #9065
Check · Review · Land · Live done — Landed and live in production.
I made the bad-endpoint test in `test/tui-backups.test.ts` wait for its screens, but I couldn't reproduce the failure, so I can't confirm this is the cause. The test passed alone and in three full runs of the file. The forge's check on this push is the real test.
shipped production is serving it deploy d909ee7
I made the bad-endpoint test in test/tui-backups.test.ts wait for its screens, but I couldn't reproduce the failure, so I can't confirm this is the cause. The test passed alone and in three full runs of the file. The forge's check on this push is the real test.
My guess is a timing race under load. The test read the first frame after enter and after esc, and under a loaded full-suite run the refusal text can land a frame later.
The fix reuses the file's existing until helper. After enter it waits for "The endpoint must be an http(s) URL", then checks "1/5". After esc it waits for the full refusal line. The assertion that nothing was sealed is unchanged.
I only changed the test, not the app code, and I didn't run bun scripts/gate.ts. bun x tsc --noEmit was clean. To try it: bun test test/tui-backups.test.ts.
Test-only change that reuses the existing until helper, so it stays small and in the file's pattern. It waits for the refusal after enter and after esc instead of reading one frame. The seal-nothing assertion is kept, and the 1/5 check now reads the settled frame. There is no app code, dependency, README or security surface to flag. I did not run it; I only read the diff and the helper.
Two things I would do next:
- The scout could not reproduce the failure, so this is a guess. If the forge check goes red here again, find the real cause (for example order or shared state with another file) and do not widen the waits.
- Move
untilinto test/helpers/tui.ts next tosettleApp, so other TUI tests can wait on a screen the same way instead of reading one frame.
I made the bad-endpoint test in
test/tui-backups.test.tswait for its screens, but I couldn't reproduce the failure, so I can't confirm this is the cause. The test passed alone and in three full runs of the file. The forge's check on this push is the real test.My guess is a timing race under load. The test read the first frame after
enterand afteresc, and under a loaded full-suite run the refusal text can land a frame later.The fix reuses the file's existing
untilhelper. Afterenterit waits for "The endpoint must be an http(s) URL", then checks "1/5". Afterescit waits for the full refusal line. The assertion that nothing was sealed is unchanged.I only changed the test, not the app code, and I didn't run
bun scripts/gate.ts.bun x tsc --noEmitwas clean. To try it:bun test test/tui-backups.test.ts.Closes #8997