Follow-up from PR #2706's review (#2682, recorded there on 2026-09-05 and moved here so #2682 can close).
What is true today. readOnMount in frontend/taskdeck-web/tests/e2e/route-affordances.spec.ts arms page.waitForResponse(...) for the calendar, metrics, notifications and home mount reads with no { timeout }. Under this repo's Playwright config there is no event timeout of its own: actionTimeout keeps the fixture default of 0, playwright.config.ts sets only timeout: 45_000 and expect.timeout: 8_000, nothing calls setDefaultTimeout, and playwright-core arms no rejection for 0 (read from the installed 1.62.1 tree during PR #2706). So a mount read that never gets a response hangs to the test timeout (90 s in the board-seeded walk, 45 s in the Home/Inbox block) and reports "Test timeout exceeded" instead of the mount-read failure, a direct hit on the shared E2E Smoke globalTimeout that the file's BUDGET section exists to protect. activate in the same file bounds its own waits with { timeout: 15_000 } for exactly this reason. Pre-existing: the inline waits PR #2706 replaced were equally unbounded.
Fix. Pass a bound to the four mount reads matching activate (one line in readOnMount plus its docblock, which today says the reads are bounded only by the test timeout), after checking CI's single-worker E2E lane timings for the first read after web-server start so the bound cannot introduce a slow-runner red. Test-only; no product change.
Refs #2682, #1949, PR #2673, PR #2679, PR #2706.
Follow-up from PR #2706's review (#2682, recorded there on 2026-09-05 and moved here so #2682 can close).
What is true today.
readOnMountinfrontend/taskdeck-web/tests/e2e/route-affordances.spec.tsarmspage.waitForResponse(...)for the calendar, metrics, notifications and home mount reads with no{ timeout }. Under this repo's Playwright config there is no event timeout of its own:actionTimeoutkeeps the fixture default of 0,playwright.config.tssets onlytimeout: 45_000andexpect.timeout: 8_000, nothing callssetDefaultTimeout, andplaywright-corearms no rejection for 0 (read from the installed 1.62.1 tree during PR #2706). So a mount read that never gets a response hangs to the test timeout (90 s in the board-seeded walk, 45 s in the Home/Inbox block) and reports "Test timeout exceeded" instead of the mount-read failure, a direct hit on the shared E2E SmokeglobalTimeoutthat the file's BUDGET section exists to protect.activatein the same file bounds its own waits with{ timeout: 15_000 }for exactly this reason. Pre-existing: the inline waits PR #2706 replaced were equally unbounded.Fix. Pass a bound to the four mount reads matching
activate(one line inreadOnMountplus its docblock, which today says the reads are bounded only by the test timeout), after checking CI's single-worker E2E lane timings for the first read after web-server start so the bound cannot introduce a slow-runner red. Test-only; no product change.Refs #2682, #1949, PR #2673, PR #2679, PR #2706.