tests/visual/serve.sh generates the fixture's myst.yml inside the fixture directory it serves: it does cd "$here/${FIXTURE_DIR:-fixture}" and then writes sed "s|__THEME__|${esc}|" myst.yml.in > myst.yml. That file is shared state, so a second instance started against the same FIXTURE_DIR overwrites the first one's config — including the THEME_TEMPLATE the first server is serving.
The committed suite is not affected, and that is worth stating plainly: the three myst start servers in playwright.config.ts use three different fixture directories (fixture, fixture-no-thebe, fixture-rtl), and the static server copies the main fixture to a gitignored .static/ working copy. Each writes its own myst.yml.
The hazard is the manual A/B comparison that tests/visual/README.md documents: serving two different theme builds to compare them. If both are pointed at the same fixture, the second serve.sh silently changes which theme the first one is serving, so the "baseline" server starts returning the candidate. Encountered while working on #225. It fails quietly — the pages still render, they are simply built from the wrong theme.
Suggested fix
Either is fine, and the first is nearly free:
- Note it in
tests/visual/README.md, next to the existing two-step baseline/candidate recipe: run the two builds sequentially, or point them at separate fixture copies.
- Have
serve.sh write myst.yml into a per-instance working copy of the fixture (as serve-static.sh already does with .static/), which removes the shared file entirely and makes concurrent use safe.
Related: the build-side trap in the same workflow is filed separately — the theme build does not clean before building, so an A/B comparison can also pick up a stale bundle.
🤖 Generated with Claude Code
tests/visual/serve.shgenerates the fixture'smyst.ymlinside the fixture directory it serves: it doescd "$here/${FIXTURE_DIR:-fixture}"and then writessed "s|__THEME__|${esc}|" myst.yml.in > myst.yml. That file is shared state, so a second instance started against the sameFIXTURE_DIRoverwrites the first one's config — including theTHEME_TEMPLATEthe first server is serving.The committed suite is not affected, and that is worth stating plainly: the three
myst startservers inplaywright.config.tsuse three different fixture directories (fixture,fixture-no-thebe,fixture-rtl), and the static server copies the main fixture to a gitignored.static/working copy. Each writes its ownmyst.yml.The hazard is the manual A/B comparison that
tests/visual/README.mddocuments: serving two different theme builds to compare them. If both are pointed at the same fixture, the secondserve.shsilently changes which theme the first one is serving, so the "baseline" server starts returning the candidate. Encountered while working on #225. It fails quietly — the pages still render, they are simply built from the wrong theme.Suggested fix
Either is fine, and the first is nearly free:
tests/visual/README.md, next to the existing two-step baseline/candidate recipe: run the two builds sequentially, or point them at separate fixture copies.serve.shwritemyst.ymlinto a per-instance working copy of the fixture (asserve-static.shalready does with.static/), which removes the shared file entirely and makes concurrent use safe.Related: the build-side trap in the same workflow is filed separately — the theme build does not clean before building, so an A/B comparison can also pick up a stale bundle.
🤖 Generated with Claude Code