verify-stack e2e crashes under memory pressure (2 Chromium workers on the 8GB runner) #115

Closed
opened 2026-07-22 11:24:52 +00:00 by not · 0 comments
Contributor

What happened: the verify-stack CI job fails intermittently on the Playwright e2e — most often registration.spec.ts — with:

Error: locator.fill: Test timeout of 90000ms exceeded.
Error: locator.fill: Page crashed
→ 1 failed, 1 flaky

First attempts take ~4.3 min; tests pass on retry only when they happen to run alone.

What you expected: verify-stack e2e passes reliably.

Root cause: tests/e2e/playwright.config.ts sets no workers cap, so Playwright runs 2 Chromium workers in parallel. On the self-hosted runner (playground-8gb-nbg1-1, 8 GB) that means two full channel: 'chromium' browsers on top of the entire compose stack (OpenZaak, NRC, Keycloak, Flowable, 4× Postgres, all .NET services + 3 portals). Memory is exhausted and the renderer is OOM-killed — Chromium reports Page crashed. The failure is a runner-memory ceiling, not a product defect (the flow passes when a browser runs alone).

Steps to reproduce: open a PR → verify-stack → e2e phase → intermittent Page crashed on the heavier registration.spec.ts.

Environment: self-hosted gitea-runner on the 8 GB Hetzner box; mcr.microsoft.com/playwright:v1.61.1-noble, run with --ipc=host.

Proposed fix: pin workers: 1 in playwright.config.ts (the two happy-path specs run serially — only two tests, both long-running), and add --disable-dev-shm-usage to the Chromium launch args. Follows CLAUDE.md §15 "flaky tests are fixed, not retried" — this removes the memory contention rather than leaning on retries.

Suspected area: area:infra (CI e2e).

**What happened:** the `verify-stack` CI job fails intermittently on the Playwright e2e — most often `registration.spec.ts` — with: ``` Error: locator.fill: Test timeout of 90000ms exceeded. Error: locator.fill: Page crashed → 1 failed, 1 flaky ``` First attempts take ~4.3 min; tests pass on retry only when they happen to run alone. **What you expected:** `verify-stack` e2e passes reliably. **Root cause:** `tests/e2e/playwright.config.ts` sets no `workers` cap, so Playwright runs **2 Chromium workers in parallel**. On the self-hosted runner (`playground-8gb-nbg1-1`, 8 GB) that means two full `channel: 'chromium'` browsers on top of the entire compose stack (OpenZaak, NRC, Keycloak, Flowable, 4× Postgres, all .NET services + 3 portals). Memory is exhausted and the renderer is OOM-killed — Chromium reports `Page crashed`. The failure is a runner-memory ceiling, not a product defect (the flow passes when a browser runs alone). **Steps to reproduce:** open a PR → `verify-stack` → e2e phase → intermittent `Page crashed` on the heavier `registration.spec.ts`. **Environment:** self-hosted `gitea-runner` on the 8 GB Hetzner box; `mcr.microsoft.com/playwright:v1.61.1-noble`, run with `--ipc=host`. **Proposed fix:** pin `workers: 1` in `playwright.config.ts` (the two happy-path specs run serially — only two tests, both long-running), and add `--disable-dev-shm-usage` to the Chromium launch args. Follows CLAUDE.md §15 "flaky tests are fixed, not retried" — this removes the memory contention rather than leaning on `retries`. **Suspected area:** area:infra (CI e2e).
not added this to the Iteration 2 — Flow Completeness milestone 2026-07-22 11:24:52 +00:00
not added the type:bugarea:infra labels 2026-07-22 11:24:52 +00:00
not closed this issue 2026-07-22 12:04:01 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#115