Skip to content
Motir
Start free

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-1699Done

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

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.