test(e2e): give the default-view redirect a realistic budget - #822
test(e2e): give the default-view redirect a realistic budget#822rubenvdlinde wants to merge 1 commit into
Conversation
`user-settings.spec.ts` "default view Meetings redirects the app root" failed at 20.9s against a 20s budget, on BOTH attempts of one run (`retries: 1`), and then PASSED on a re-run of the identical sha. Nothing about the app changed — the budget was never realistic for the work. The test does three full app navigations (settings panel, app root, deep link), each blocking on the pre-mount initializeStores() round trip. The restore comment already recorded the arithmetic from an earlier flake fix: the redirect lands at 10.6s and the deep link holds at 17.6s. That is ~2s of headroom, so a merely busy runner tips it over.⚠️ The 20s comes from `tests/e2e/playwright.config.ts`, NOT the 30s root `playwright.config.ts`. CI resolves the config through `playwright-test-path`, so the root file — the one you find first — is not the one that governs this run. Worth knowing before reading a timeout number off the wrong config, as I did. 60s deliberately, not the 120s the facet specs use: enough that load cannot fail it, small enough that a genuine hang still fails this test rather than burning the job's 45-minute cap. This is the flake that made decidesk's development branch read red while the code was fine, which is the expensive kind — it trains people to re-run rather than read.
|
Cross-reference: #821 ( |
Quality Report — ConductionNL/decidesk @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| check-nav-ceiling | ✅ | ||||
| test-l10n | ✅ | ||||
| format | ✅ | ||||
| composer | ✅ | ✅ 104/104 | |||
| npm | ✅ | ✅ 538/538 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ✅ | ||||
| Newman | ✅ | ||||
| Playwright | ✅ | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-08-21 09:01 UTC
Download the full PDF report from the workflow artifacts.
|
Closing as a duplicate — #821 landed the same fix first and did it better. Both PRs diagnosed the same defect independently and reached the same arithmetic: the test needs the settings panel plus three full app navigations, ~16s of a 20s budget, so it fails on load rather than on defect (it passed at 05:54 and timed out at 07:08 on unchanged code). #821 uses The one thing worth carrying over from this PR's description, since it cost me time to establish: the 20s comes from |
user-settings.spec.ts— "default view Meetings redirects the app root to the meetings list" — failed at 20.9s against a 20s budget, on both attempts of one run (retries: 1), then passed on a re-run of the identical sha. Nothing about the app changed between those runs.Why it is under-budgeted. The test does three full app navigations — settings panel, app root, deep link — each blocking on the pre-mount
initializeStores()round trip. The restore comment in the test already recorded the arithmetic from an earlier flake fix: the redirect landed at 10.6s and the deep link held at 17.6s. That is roughly 2 seconds of headroom, so a merely busy runner tips it over.playwright.config.tssaystimeout: 30_000; the governing value istimeout: 20_000intests/e2e/playwright.config.ts, because CI resolves the config throughplaywright-test-path. I read the wrong file first and had to chase the discrepancy — worth stating so the next person does not.60s deliberately, not the 120s the facet specs use: enough that load cannot fail it, small enough that a genuine hang still fails this test rather than burning the job's 45-minute cap.
Why it is worth fixing rather than re-running. This flake made decidesk's
developmentread red while the code was fine — it is the expensive kind, because it trains people to re-run rather than read. It also cost real time here: it appeared on the run for a formatter sweep, so the first hypothesis was that the sweep had changed behaviour. Re-running the same sha is what ruled that out.