MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-1699

E2E flake (recurring, 4 PRs): project-isolation.spec.ts:203 — captureSetActiveProjectAction waitForResponse 10s timeout on bulk-4 under load

Done
Description

Symptom

Playwright E2E (bulk-4) flakes on tests/e2e/project-isolation.spec.ts:203 (@smoke cross-tenant Server Action denied + switcher-shows-own-projects). The failure is a TimeoutError: page.waitForResponse: Timeout 10000ms exceeded inside the setup helper captureSetActiveProjectAction (project-isolation.spec.ts:181), waiting for the setActiveProject Server Action POST (next-action header). It fails on the initial run and retry #1 (the shard's webServer is degraded for that worker, so the retry inherits the slow server).

Recurrence (diff-unrelated every time — the tell it's the harness, not the diff)

Hit on PR #1572, #1574, #1577, and now #1582 — all with diffs that touch NOTHING in the switcher / Server Action / project-isolation path (#1577 + #1582 were backend-only migrate-onboarding work). Every other check is green each time (TypeScript, Lint, Next build, all other E2E shards, Vitest + coverage, CLA). Passes on main.

Root cause (hypothesis)

Even under the PR #1565 prod-build harness (MOTIR-1679's cure for the next dev OOM), this spec's setup is unusually heavy — a two-context sign-up + three project creates before the measured action — so on the bulk-4 worker the server creeps over the cliff and the FIRST setActiveProject Server Action's response exceeds the tight 10s waitForResponse budget. This is the same class as the acceptance-video first-hit timeout (fixed by bumping 20s→60s) and the board-scrum locator (prod-build-exposed), which got real fixes rather than perpetual re-runs.

Fix directions

  1. Bump the waitForResponse timeout in captureSetActiveProjectAction from 10s to ~30s (mirrors the acceptance-video 60s bump) — the cheapest durable fix; the assertion is about denial/isolation, not latency.
  2. And/or lighten the shard: move this heavy two-context/3-project spec off the crowded bulk-4 leg (its own leg or a lighter shard), or pre-warm the setActiveProject route before the measured action.
  3. Confirm no genuine server-side slowness on first setActiveProject hit under the prod harness.

Notes

Logged in the auto-flake-log across 4 PRs; this is the escalation at the "one more occurrence → file a bug" threshold. Related to MOTIR-1679 (the prod-build harness family, which reduced but did not eliminate this bulk-4 mode). Surfaced while shipping MOTIR-931 (PR #1582), whose own diff is innocent.