Your Playwright suite suddenly fails with "Executable doesn't exist at .../chromium-1244/..." after a dependency update. What happened?

## What the message is really saying `Executable doesn't exist at ...` is thrown when Playwright resolves the path where the engine build for *this* Playwright version should be and finds nothing there. The message includes the path it looked at and an ASCII box that says Playwright was just installed or updated and names the command to fix it. The revision in the path — `chromium-1244` and friends — is the clue: engine builds are stored in **revision-stamped folders**, and the revision comes from the `browsers.json` manifest inside the installed `playwright-core` package. So the sentence to say in an interview is: the package version moved, the expected revision moved with it, and nobody re-ran the install. ## The usual causes, in order of likelihood 1. **A dependency bump.** Someone upgraded `@playwright/test`. The new version expects a newer engine revision, the old build is still on disk under its old folder name, and the download step never ran. A fresh clone of the hotel-booking repo is the same story: `node_modules` is populated, the engine cache is empty. 2. **A path mismatch.** `PLAYWRIGHT_BROWSERS_PATH` is set for one half of the work and not the other, so the install wrote to one directory and the run looks in another. The build exists; the runtime is looking somewhere else. 3. **Housekeeping removed it.** Playwright deletes builds that no installation still references, so downgrading, or removing the checkout that pinned an old version, can take a build with it. 4. **A partial or corrupted download.** Rarer, and it usually shows as a build that exists but will not start rather than one that is absent. ## Fixing it - Run `npx playwright install` — the error text names this command, and on a version bump it is the whole fix. Add an engine name to narrow it. - Run `npx playwright install --list` first when you want evidence: it prints the builds present across every Playwright installation on the machine, so you can see whether the expected revision is genuinely missing or merely in another directory. - Use `--force` when a build is present but suspect; it reinstalls rather than skipping what looks already installed. - If `PLAYWRIGHT_BROWSERS_PATH` is in play, set it identically for the install and the run, and prefer an absolute path so both halves agree. ## Stopping it from recurring The durable fix is to stop treating the engine download as a thing humans remember. Tie it to the dependency install so that whatever refreshes `node_modules` also refreshes the engines, and keep the Playwright version pinned in the lockfile so the expected revision only moves when someone deliberately moves it. Two habits do most of the work: - **Upgrade Playwright as one act**: change the version, run the install, commit both. - **Make the first failure legible**: this error is loud and self-describing, so resist wrapping the run in a script that swallows the message — the box in the output already contains the answer. ## What it is not It is not a flaky test, a bad locator, or an application problem in the booking flow. It fires before any page is opened, it fires identically for every test, and it names a filesystem path. Treat any suite-wide, instantaneous, path-naming failure as an environment problem and check the engine cache before reading a single test.