Skip to content

fix(e2e): give the viewport-loop test a budget larger than its own waits - #1054

Merged
rubenvdlinde merged 1 commit into
developmentfrom
fix/e2e-urgent-filter-timeout
Aug 31, 2026
Merged

fix(e2e): give the viewport-loop test a budget larger than its own waits#1054
rubenvdlinde merged 1 commit into
developmentfrom
fix/e2e-urgent-filter-timeout

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

quick-filter dropdown label "All urgent" renders intact at every tested viewport failed as a bare:

Test timeout of 20000ms exceeded.

The test could not pass reliably no matter how healthy the app was.

playwright.config.ts sets timeout: 20_000 per test. This one loops three viewports, and each iteration navigates and then allows waitForSelector(15_000) plus expect(select).toBeVisible({ 10_000 })25s of permitted waiting in the first iteration alone, against a 20s total budget.

The symptom is misleading in a specific way: a whole-test timeout names no element, so it reads like a slow or broken dropdown rather than a budget that was never large enough for the work the test does. The spec itself is a deliberate regression guard (its header notes the reported "All u rgent" split did not reproduce), so there was no defect to find in the dropdown.

The fix

test.setTimeout(90_000), matching the sibling multi-step specs — voting-rules.spec.ts uses 90_000, goals-pages.spec.ts uses 120_000, agenda-management.spec.ts uses 35_000. This spec had none.

The per-step waits are deliberately left untouched, so a genuinely stuck dropdown still fails on its own 10s assertion with a message naming the element, rather than on a whole-test timeout that names nothing.

Scope

This is the fourth and last of decidiq's E2E failures. The other three are separate causes, fixed separately:

`quick-filter dropdown label "All urgent" renders intact at every tested
viewport` failed as a bare:

    Test timeout of 20000ms exceeded.

The test could not pass reliably no matter how healthy the app was.
playwright.config.ts sets `timeout: 20_000` per test. This one loops THREE
viewports, and each iteration navigates and then allows
`waitForSelector(15_000)` plus `expect(select).toBeVisible({ 10_000 })` -- 25s
of permitted waiting in the FIRST iteration alone, against a 20s total budget.

The symptom is misleading in a specific way: a whole-test timeout names no
element, so it reads like a slow or broken dropdown rather than a budget that
was never large enough for the work the test does.

90s matches the sibling multi-step specs (voting-rules.spec.ts uses 90_000;
goals-pages.spec.ts uses 120_000) and the per-step waits are left untouched, so
a genuinely stuck dropdown still fails on its OWN 10s assertion with a message
naming the element.

The fourth and last of decidiq's E2E failures. The other three: two seeding
gaps in #1052, one strict-mode locator violation in #1053.
@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/decidiq @ 1047428

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
check-manifest
check-nav-ceiling
test-l10n
format
check-l10n-js
check-schema-l10n
composer ✅ 104/104
npm ✅ 537/537
app:check-code ⏭️
info.xml
REUSE
PHPUnit
Newman
Playwright 🚨 NO VERDICT — enabled but never ran
Hydra gates

Quality workflow — 2026-08-31 08:48 UTC

Download the full PDF report from the workflow artifacts.

@rubenvdlinde
rubenvdlinde merged commit 676eee9 into development Aug 31, 2026
49 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant