Altinity / Altinity/altinity-sql-browser

Parallel-worktree Playwright runs silently serve another worktree's source

Aperta
#560 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

bug inbox
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 webServer port 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: false so a run always owns its own server; and/or
  • have build/e2e-serve.mjs refuse to be reused by a different checkout — e.g. serve a /__root probe 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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. 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

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.