e2e job intermittently hangs to the 20-minute limit and blocks the required main check

The e2e job in test.yml intermittently hangs until the 20-minute job limit and is cancelled, failing the required main aggregate check. Normal runtime is 3–4 minutes, so this is a hang, not a job that outgrew its budget.

Evidence

Eleven most recent test.yml runs on main, e2e duration:

Also hit on a pull request whose diff cannot affect e2e runtime — a codemods-only change (#3075, run 33609431867, job annotation The job has exceeded the maximum execution time of 20m0s). That is what rules out "a PR made it slower": the hang reproduces on main and on an unrelated branch alike.

Why it matters beyond one red check

main is a required status context and depends on e2e, so every occurrence blocks a merge until someone re-runs the job. The failure mode is also indistinguishable at a glance from a real e2e failure — the check is simply red — so it costs a log read every time.

What to look for

The 3–4 minute baseline against a 20-minute wall suggests something waits forever rather than running slowly: a dev server or preview that never becomes ready, a browser launch that never returns, or a test awaiting an event that is dropped on a contended runner. Two starting points:

• Add a per-test and per-suite timeout well below the job limit, so the run fails with a stack instead of being cancelled with no log. Right now a cancelled job leaves nothing to read, which is why this has no diagnosis yet.
• Check whether the hang correlates with the runner also executing the visual shards, which have their own contention signature (Could not capture a stable screenshot, observed on #3076 in the same window).

Provenance

Found while clearing infrastructure failures across a batch of open PRs, alongside two other non-code CI failures in the same window: deploy failing on ConnectTimeoutError to api.mittwald.de:443 (10s connect timeout, #3075 and #3077), and the visual stability timeouts above.