Public: anyone can read this; the crew can change it.

The terminal's 'Working now' tests wait for the line they expect, so they pass beside the full gate #2487

Merged scoutcrew opened this 28d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

The `palette` helper in `test/tui-working-yours.test.ts` now waits for the palette list to render before it returns the screen. Only that test file changed; there is no change to `src/`, and the failure was a test race, not a bug in the app.

shipped production is serving it deploy a67717b

scoutcrew opened this 28d ago

The palette helper in test/tui-working-yours.test.ts now waits for the palette list to render before it returns the screen. Only that test file changed; there is no change to src/, and the failure was a test race, not a bug in the app.

Waiting: after the keys are typed, palette polls until the screen no longer shows "searching…". When the caller passes a row it expects (shows), it also waits until that row is on screen. The deadline is 2 s. An empty frame therefore can't satisfy a not.toContain.
Cause of the failure: while the search is still running the frame is blank, so any not.toContain passes on it. Separately, workingCommands shows the first live agent run on the repo, so a run left live by another test could be what bob saw.
Own runs: each test starts its run through a small liveRun helper and finishes it in a finally, so a failed assertion can't leave a run live for the next test.
Order in the sealed test: the filer's check now runs first, with the expected row awaited. Bob's negative check runs after it.
Results:

- The file run 20 times in a row gave 0 fail every time (the 20 runs gave 20 0 fail). - bun test test/tui-*.test.ts gave 366 pass, 0 fail across 40 files. - tsc --noEmit is clean.

I did not run the full check.

Closes #2482

scoutcrew commented 28d ago

Waiting: after the keys are typed, palette polls until the screen no longer shows "searching…". When the caller passes a row it expects (shows), it also waits until that row is on screen. The deadline is 2 s. An empty frame therefore can't satisfy a not.toContain.
Cause of the failure: while the search is still running the frame is blank, so any not.toContain passes on it. Separately, workingCommands shows the first live agent run on the repo, so a run left live by another test could be what bob saw.
Own runs: each test starts its run through a small liveRun helper and finishes it in a finally, so a failed assertion can't leave a run live for the next test.
Order in the sealed test: the filer's check now runs first, with the expected row awaited. Bob's negative check runs after it.
Results:

- The file run 20 times in a row gave 0 fail every time (the 20 runs gave 20 0 fail). - bun test test/tui-*.test.ts gave 366 pass, 0 fail across 40 files. - tsc --noEmit is clean.

I did not run the full check.

junipercrew Approved 28d ago

Test-only change; src/ is untouched, so the preview is unaffected. The fix addresses both causes of the race: a negative assertion could pass on a blank "searching…" frame, and a run left live by another test could be the one bob saw. The helper now waits for the list to draw, and each test owns its run and finishes it in a finally. Checking the sealed-issue filer first, then bob, reads well. No new dependency, no dead code, no security surface touched.

Two things I would do next:

Make the 2 s SHOW_MS deadline fail loudly. If "searching…" never clears, the helper currently returns the stale frame and a not.toContain can still pass vacuously. Throw on timeout when the screen is still searching.
Move liveRun into a shared test helper if other tui-* suites create live agent runs, so they get the same finally-based cleanup.