CI failure
The failure occurred about 13 minutes before the Slack alert and is the actual failed matrix job, not a cancellation/rerun artifact. All 1,332 job-log lines were available and reviewed.
Failure evidence
FAIL unit src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx
> SchedulePage > cron tests > case 0 has the correct expected time
Error: Timed out in waitFor.
❯ waitForWrapper .../@testing-library/dom/dist/wait-for.js:162:27
❯ fillForm src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx:20:8
20| await waitFor(() => screen.findByLabelText("Start time"));
❯ src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx:88:10
Test Files 1 failed | 198 passed (199)
Tests 1 failed | 3079 passed | 2 skipped (3082)
The timeout DOM snapshot already contains the labeled input:
<label for="_r_2_">Start time</label>
<input id="_r_2_" name="time" type="time" value="00:00" />
There are secondary shutdown warnings (close timed out after 1000ms and a prior passing file's worker-termination timeout), but this was a single assertion timeout rather than a process panic/OOM/crash.
Root-cause assessment
Classification: Flaky test — timing-dependent nested async query.
fillForm wraps an already-waiting findByLabelText query in another default-timeout waitFor:
await waitFor(() => screen.findByLabelText("Start time"));Under the 8-worker CI load, the outer and inner waits share roughly the same one-second timeout. The final DOM proves the input rendered, so the failure is the test's readiness synchronization rather than a missing label or API error. This should use the async query directly, for example:
await screen.findByLabelText("Start time");A component refactor merged about an hour before this failure in coder/coder#27563, replacing the MUI time/select fields with FormField and Radix Select. It may have shifted render timing enough to expose the existing nested-wait anti-pattern, although that PR did not modify fillForm.
Duplicate search
No matching issue was found after searches for:
- exact test:
"case 0 has the correct expected time"
- test file:
"SchedulePage.test.tsx"
- error + suite:
"Timed out in waitFor" "SchedulePage"
"quiet hours" flake"correct expected time"- broader
test-js "Timed out in waitFor"
- closed
SchedulePage/waitFor issues from the last 30 days
Broader waitFor flakes in other test files have different code paths and failure modes, so they are not duplicates.
Assignment analysis
Commands/line ranges used for ownership tracing:
git blame -L 9,31 site/src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx
git blame -L 58,92 site/src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx
git log --oneline -10 --follow -- site/src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx
git log --oneline -20 -- site/src/pages/UserSettingsPage/SchedulePage
The failing helper, including the nested waitFor(() => findByLabelText(...)), traces to the original quiet-hours page implementation, commit efe804498b7d903b19afaddabd24a127595a472c, coder/coder#9676, by aslilac. Later changes to the test file are predominantly formatting/import/tooling changes; the latest component change is #27563 by jakehwll and left this helper unchanged.
Per test-function ownership priority, assigning aslilac.
Reproduction
No deterministic local reproduction is confirmed. Stress the affected test with CI-like concurrency/repetition:
cd site
pnpm vitest run --project=unit src/pages/UserSettingsPage/SchedulePage/SchedulePage.test.tsx --max-workers 8
Repeat the command or run the full pnpm test:ci --max-workers 8 suite to increase scheduling contention.
CI failure
test-js(90335547986)eb905702c80a5c6f9f08512ac3eb5059b7e62245The failure occurred about 13 minutes before the Slack alert and is the actual failed matrix job, not a cancellation/rerun artifact. All 1,332 job-log lines were available and reviewed.
Failure evidence
The timeout DOM snapshot already contains the labeled input:
There are secondary shutdown warnings (
close timed out after 1000msand a prior passing file's worker-termination timeout), but this was a single assertion timeout rather than a process panic/OOM/crash.Root-cause assessment
Classification: Flaky test — timing-dependent nested async query.
fillFormwraps an already-waitingfindByLabelTextquery in another default-timeoutwaitFor:Under the 8-worker CI load, the outer and inner waits share roughly the same one-second timeout. The final DOM proves the input rendered, so the failure is the test's readiness synchronization rather than a missing label or API error. This should use the async query directly, for example:
A component refactor merged about an hour before this failure in coder/coder#27563, replacing the MUI time/select fields with
FormFieldand RadixSelect. It may have shifted render timing enough to expose the existing nested-wait anti-pattern, although that PR did not modifyfillForm.Duplicate search
No matching issue was found after searches for:
"case 0 has the correct expected time""SchedulePage.test.tsx""Timed out in waitFor" "SchedulePage""quiet hours" flake"correct expected time"test-js "Timed out in waitFor"SchedulePage/waitForissues from the last 30 daysBroader waitFor flakes in other test files have different code paths and failure modes, so they are not duplicates.
Assignment analysis
Commands/line ranges used for ownership tracing:
The failing helper, including the nested
waitFor(() => findByLabelText(...)), traces to the original quiet-hours page implementation, commitefe804498b7d903b19afaddabd24a127595a472c, coder/coder#9676, byaslilac. Later changes to the test file are predominantly formatting/import/tooling changes; the latest component change is #27563 byjakehwlland left this helper unchanged.Per test-function ownership priority, assigning
aslilac.Reproduction
No deterministic local reproduction is confirmed. Stress the affected test with CI-like concurrency/repetition:
Repeat the command or run the full
pnpm test:ci --max-workers 8suite to increase scheduling contention.