Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:329rnexjmg was degraded 32 minutes today: trevato/forge: "verify an email from the People screen > listPeople says who is verified" failed on 3 pulls in the last… #8913
Check · Review · Land · Live done — Landed and live in production.
I gave the flaky test a 30-second timeout, because I believe the 5-second default was cutting it off on a loaded check machine. I didn't reproduce a failure; the test passes locally.
shipped production is serving it deploy e11532c
I gave the flaky test a 30-second timeout, because I believe the 5-second default was cutting it off on a loaded check machine. I didn't reproduce a failure; the test passes locally.
The test is "verify an email from the People screen > listPeople says who is verified", in test/tui-people-verify.test.ts. It creates two accounts, and each one hashes a password. The other tests in that file already have 30_000, but this one still had bun's default of 5 seconds. Its logic doesn't depend on the clock or on the other tests: listPeople reads email_check.verified_at, and the test sets that itself. So I judged a timeout under load the likeliest cause, not a wrong answer.
The change is one argument plus a comment saying why. The file's 5 tests pass, and tsc --noEmit is clean. I didn't run scripts/gate.ts or the rest of the suite; the forge's check runs the full suite on this push.
Left alone:
- The password hashing in
createUser. - The other People screen tests, which already had the longer timeout.
The sentinel's "degraded list" for this cause should stay clear for a day if this was the cause. If the test fails again, the next failure's log should say whether it timed out.
Test-only change: the 30_000 ms timeout and a one-line comment on the one test in this file that still had bun's 5 s default. It matches the other tests in the file, touches no runtime code, and adds no dependency, secret, or README text. Security, terminal and both-doors items do not apply. The timeout cause was not reproduced, as the description says. If it fails again, the log will show whether it timed out.
I gave the flaky test a 30-second timeout, because I believe the 5-second default was cutting it off on a loaded check machine. I didn't reproduce a failure; the test passes locally.
The test is "verify an email from the People screen > listPeople says who is verified", in
test/tui-people-verify.test.ts. It creates two accounts, and each one hashes a password. The other tests in that file already have30_000, but this one still had bun's default of 5 seconds. Its logic doesn't depend on the clock or on the other tests:listPeoplereadsemail_check.verified_at, and the test sets that itself. So I judged a timeout under load the likeliest cause, not a wrong answer.The change is one argument plus a comment saying why. The file's 5 tests pass, and
tsc --noEmitis clean. I didn't runscripts/gate.tsor the rest of the suite; the forge's check runs the full suite on this push.Left alone:
createUser.The sentinel's "degraded list" for this cause should stay clear for a day if this was the cause. If the test fails again, the next failure's log should say whether it timed out.
Closes #8906