Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:329rnexjmg is past its budget: trevato/forge: "verify an email from the People screen > listPeople says who is verified" failed on 3 pulls in the last… #7705
Check · Review · Land · Live done — Landed and live in production.
The test "verify an email from the People screen > listPeople says who is verified" now depends only on `listPeople`, not on whether the earlier tests in its file finished.
shipped production is serving it deploy bf488b2
The test "verify an email from the People screen > listPeople says who is verified" now depends only on listPeople, not on whether the earlier tests in its file finished.
Cause. The test read state left by the TUI tests before it in test/tui-people-verify.test.ts. It expected bobby to be verified because the first test pressed v y on the People screen, and carol to be unverified because the third test created her. Those TUI tests wait up to 20 s for the screen to settle, but bun's default limit per test is 5 s. On a loaded check machine a TUI test could hit that limit before bobby was verified, and the listPeople test then failed with it. That made it red on several pulls whose code had nothing to do with it.
Change.
- The
listPeopletest now creates its own two accounts: dora, marked verified, and evan, left unverified. It checks those two and the seeded admin, alice. It passes run alone (-t listPeople) and with the rest of the file. - The three TUI tests get the 30 s limit that other TUI suites (such as
tui-about-detach) already use, so their own verdict doesn't depend on load either. - No app code changed. This test was wrong, not the code it tests.
Not done. I did not look through other TUI suites for the same reliance on earlier tests.
To try: bun test test/tui-people-verify.test.ts (4 pass), and bun x tsc --noEmit is clean.
🤖 Generated with Claude Code
Test-only fix, and the right one: the listPeople test now makes its own verified (dora) and unverified (evan) accounts, so it no longer depends on the TUI tests before it. The 30 s limit on the three TUI tests matches other TUI suites. No app code, no new dependency, and the pull is green. There is no UI or security surface to judge here. Two things to do next: (1) check other TUI suites for the same reliance on earlier tests (you said you skipped this); (2) assert in listPeople that bobby is not verified when no TUI test has run, or drop the seeded bobby from beforeAll if only the screen tests use them.
The test "verify an email from the People screen > listPeople says who is verified" now depends only on
listPeople, not on whether the earlier tests in its file finished.Cause. The test read state left by the TUI tests before it in
test/tui-people-verify.test.ts. It expected bobby to be verified because the first test pressedv yon the People screen, and carol to be unverified because the third test created her. Those TUI tests wait up to 20 s for the screen to settle, but bun's default limit per test is 5 s. On a loaded check machine a TUI test could hit that limit before bobby was verified, and thelistPeopletest then failed with it. That made it red on several pulls whose code had nothing to do with it.Change.
listPeopletest now creates its own two accounts: dora, marked verified, and evan, left unverified. It checks those two and the seeded admin, alice. It passes run alone (-t listPeople) and with the rest of the file.tui-about-detach) already use, so their own verdict doesn't depend on load either.Not done. I did not look through other TUI suites for the same reliance on earlier tests.
To try:
bun test test/tui-people-verify.test.ts(4 pass), andbun x tsc --noEmitis clean.🤖 Generated with Claude Code
Closes #7670