Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:l7ak92kn4l is past its budget: trevato/forge: "report a problem in the terminal > the palette has the row" failed on 3 pulls in the last hour — the la… #7407
Check · Review · Land · Live done — Landed and live in production.
I changed the test "report a problem in the terminal > the palette has the row", but I could not reproduce the failure, so the diagnosis below is not confirmed. The test passed here before and after the change, and `bun x tsc --noEmit` is clean. I ran only `test/tui-report.test.ts`; the forge's check will run the full suite.
shipped production is serving it deploy 9b150b4
I changed the test "report a problem in the terminal > the palette has the row", but I could not reproduce the failure, so the diagnosis below is not confirmed. The test passed here before and after the change, and bun x tsc --noEmit is clean. I ran only test/tui-report.test.ts; the forge's check will run the full suite.
Cause (a guess): the test opened the : palette and read the bare, unfiltered command list off a 40-row screen. That list is clipped to the screen, so whether "alice/lobby — Report a problem" appears depends on where it falls among the repo screen's other commands. I read the code to get there; I didn't see the failing log.
Change: test/tui-report.test.ts now types report after :, so the palette filter puts the row on screen. The test still asserts that the palette offers the row. Nothing in src/ changed.
What I left out: I didn't change how the palette lists or clips rows, and I didn't hunt for other tests that read the bare palette the same way.
To try it: bun test test/tui-report.test.ts. The forge's check on this push should show whether the failure is gone.
Test-only, single-purpose fix for a flaky assertion; nothing in src/ changes, so no security surface. The bare : palette is clipped to the 40-row screen, so asserting a row's presence in it depended on how many other commands the repo screen registered; filtering by report puts the row on screen deterministically and matches the pattern the next test in this file already uses ([":", "report", ...]). The assertion still proves the palette offers the row to a non-owner. bun test test/tui-report.test.ts: 4 pass. Preview answers 200 on /.
Not blocking: test/tui-tell.test.ts:82 and test/tui-notes.test.ts:115 assert .not.toContain on the same bare clipped palette, so they could pass even when the row they guard against is offered but clipped off-screen. They would be worth filtering the same way in a follow-up.
No new change this turn. The fix from my earlier push is still the one on the branch, and I couldn't reproduce the failure here. I can't see the check's logs, so the cause is still a guess.
What I did:
- I ran the original, unfixed test 12 times in parallel to simulate a loaded machine. All 12 passed, so load and timing are not the trigger.
- That points to the screen contents instead. The palette draws at most about 31 rows on a 40-row terminal. The bare
:list is every repo-screen command, so the "alice/lobby — Report a problem" row can fall below the visible rows when the check machine builds more commands than this clone does.
The change: test/tui-report.test.ts types report after :, so the palette filters to the row before the screen is read. The test asserts the same thing as before, and the other tests in that file already filter this way. It passed here after the change, and bun x tsc --noEmit is clean.
The sentinel's latest count: "4 pulls" most likely counts pulls whose checks ran before this fix and still carry the old test. If the failure continues after a pull based on this branch passes its check, the cause is something else, and the check's log is what's needed to find it.
Left out: I didn't change how the palette clips or lists rows.
I merged main into the branch and pushed it. After the merge the branch has no differences from main, so this pull now changes nothing on its own.
main had already made the same fix. test/tui-report.test.ts now filters the palette with Report a, where my version typed report. I took main's version for the conflict. test/tui-report.test.ts passes (4 tests); I didn't run the other test files.
The cause I gave is still a guess, because I never saw the failing check's log and could not reproduce the failure here. It was that the unfiltered : palette is clipped to the screen, so the "Report a problem" row can fall out of view. The same fix on main now covers it. If the sentinel still lists the degraded cause after main goes green, the failure has another cause, and the check's log is what I need to find it.
This pull can probably be closed as redundant, as there is nothing left in it to merge.
I changed the test "report a problem in the terminal > the palette has the row", but I could not reproduce the failure, so the diagnosis below is not confirmed. The test passed here before and after the change, and
bun x tsc --noEmitis clean. I ran onlytest/tui-report.test.ts; the forge's check will run the full suite.Cause (a guess): the test opened the
:palette and read the bare, unfiltered command list off a 40-row screen. That list is clipped to the screen, so whether "alice/lobby — Report a problem" appears depends on where it falls among the repo screen's other commands. I read the code to get there; I didn't see the failing log.Change:
test/tui-report.test.tsnow typesreportafter:, so the palette filter puts the row on screen. The test still asserts that the palette offers the row. Nothing insrc/changed.What I left out: I didn't change how the palette lists or clips rows, and I didn't hunt for other tests that read the bare palette the same way.
To try it:
bun test test/tui-report.test.ts. The forge's check on this push should show whether the failure is gone.Closes #7390