Altinity / Altinity/altinity-sql-browser
Parallel-worktree Playwright runs silently serve another worktree's source
Nessuno ha ancora preso questa issue.
- Lingua principale
- TypeScript
- Stelle
- 8
- Fork
- 2
- Merge medio
- 1h 34m
- PR unite (30g)
- 6
Descrizione
What
Parallel Playwright runs in different git worktrees of this repo silently serve each other's files, producing failures that have nothing to do with the branch under test.
playwright.config.js sets reuseExistingServer: !process.env.CI and the webServer binds a fixed default port. Every worktree uses the same config, so the second worktree to start a run finds the port already bound, skips launching its own build/e2e-serve.mjs, and attaches to the first worktree's server — which raw-serves that worktree's /src and tests/e2e. The specs then run against another branch's source with no warning.
How it showed up
During a multi-worktree /ship run (PRs #554–#558), three separate workers reported e2e failures in tests/e2e/tile-open-workbench.spec.js — one reported 4 failures, another 2, on branches that touch nothing related. One worker "confirmed" them as pre-existing by git stash-ing its own changes, which of course changed nothing, because its own files were never being served. CI was green on main and on all five branches the whole time.
Cost: a wrong conclusion that main had failing e2e specs, plus wasted diagnosis on all three workers.
Suggested fix
Make the harness worktree-safe rather than relying on discipline:
- derive the
webServerport per checkout (hash the repo root path, or read an env var the npm script sets) so concurrent worktrees cannot collide; and/or - set
reuseExistingServer: falseso a run always owns its own server; and/or - have
build/e2e-serve.mjsrefuse to be reused by a different checkout — e.g. serve a/__rootprobe returning its own absolute repo path, and let the config assert it matches before any spec runs. The assertion is the valuable part: it converts a silent wrong-source run into an immediate, legible failure.
A related smaller footgun in the same class: two vitest runs in one worktree clobber each other's coverage/.tmp and report phantom test failures with an unrelated ENOENT … coverage-*.json rejection. Worth at least a note in docs/DEVELOPMENT.md.
Why deferred
Test-infrastructure defect found while shipping unrelated bug/low issues; not in scope for any of them.
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia ispezionando playwright.config.js e build/e2e-serve.mjs, quindi esamina il fallimento dei worktree paralleli descritto per tests/e2e/tile-open-workbench.spec.js. Verifica che i worktree concorrenti non possano riutilizzare silenziosamente il server di un altro checkout e che una mancata corrispondenza causi un errore chiaro prima dell’esecuzione delle spec. Valuta di documentare il problema di coverage correlato di Vitest in docs/DEVELOPMENT.md se rimane nell’ambito.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- git, javascript, playwright, typescript
- Ambito
- developer-experience, testing-qa, tooling
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 55/100