Zombie browser process from the prevoius run connects to vitest WebSocket endpoint

[dmaretskyi]

Describe the bug

I've noticed that vitest running in browser mode sometimes reports test files from previous runs:

Only the sanity.test.ts file should have run, which is quite explicitly specified in the config: include: ['src/sanity.test.ts'],. The storage.browser.test.ts and bench.browser.test.ts files are from me prevoiusly running vitest in an unrelated package. Vitest wasn't running in the workspace mode.

After a lot of debugging it seems like configuration is indeed ok and vitest opens the browser page with a proper URL: http://localhost:5173/?id=no-isolate&path=src%2Fsanity.test.ts

The problem lies in that the browser automation process for chrome (both playwright and webdriverio) tends to keep running even after the vitest main process has exited. In my case specifically, the browser from the prevoius test run (on storage) was still running with the page open. As soons as the WebSocket endpoint was available again, it reconnected and tried running its own tests with a file list that was configured in the page URL. This also meant the test files from the previous run were reported in the CLI.

In my experience using playwright in node, the issue of the browser process sticking around after the NodeJS process has exited is quite common. I suggest guarding against rouge processes connection to the WebSocket endpoint by introducing a token specific to this test run. The token will be passed through the page URL when running tests, and validated upon the browser page connecting the WebSocket endpoint.

Reproduction

Repository with a minimal reproduction: https://github.com/dmaretskyi/vite-issue-5165

1. Have two seprate vitest setups with different sets of test files.
2. Run tests in chrome browser on macos.
3. Observe the chrome process continue to run after the test have finished (will appear as "Google Chrome" or "chromedriver" in the Activity Manager).
4. Now run tests (same browser setup) in a different package.
5. CLI output should show filenames from the prevous test run.

System Info

System:
    OS: macOS 14.0
    CPU: (10) arm64 Apple M1 Pro
    Memory: 334.25 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.0 - ~/.nodenv/versions/18.19.0/bin/node
    npm: 10.2.3 - ~/.nodenv/versions/18.19.0/bin/npm
    pnpm: 8.12.1 - ~/.nodenv/versions/18.19.0/bin/pnpm
    bun: 1.0.25 - ~/.bun/bin/bun
  Browsers:
    Chrome: 121.0.6167.160
    Safari: 17.0

### Used Package Manager

pnpm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

[github-actions[bot]]

Hello @dmaretskyi. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with need reproduction will be closed if they have no activity within 3 days.

[dmaretskyi]

Hi @sheremet-va , thanks for taking a look at the issue. I've added a github repository with the reproduction.

[hi-ogawa]

Thanks for the reproduction.

I'm testing it on my ArchLinux PC and indeed I can see pnpm nx vitest project1 is leaving chromedriver process. But, when I run vitest cli directly (e.g. cd project1 && pnpm vitest run), it looks fine without zombie process. Can you confirm this behavior on Mac? Or does the issue happen regardless nx?

(btw, I totally get the potential issue of zombie process reconnecting to the next run, which could happen for whatever reason. I just want to make sure if there's anything specific with nx integration since those are not what Vitest team officially supports.)

[AriPerkkio]

This seems very similar to https://github.com/vitest-dev/vitest/pull/5056#issuecomment-1921969349. We've also seen this issue coming up in CI randomly. I've tried to reproduce this issue many times without success so happy to see a reproduction case that brings up the bug constantly. I think the browser mode has had this bug ever since it was implemented.

I suggest guarding against rouge processes connection to the WebSocket endpoint by introducing a token specific to this test run. The token will be passed through the page URL when running tests, and validated upon the browser page connecting the WebSocket endpoint.

This sounds like a good idea. Maybe Vitest should also log a warning when previous run's process is trying to connect.

[dmaretskyi]

@hi-ogawa I was only able to reproduce the issue with zombie processes with NX. Although, from reading NX executor source code, they don't seem to be doing anything special with vitest. Likely the issue is caused by how NX handles it's child processes, maybe they kill them preemtively, which causes zombies to hang around?

[AriPerkkio]

This issue is no longer reproducible with latest Vitest v2.1.2 version. I can reproduce this 100% times with the older v1 that's used in the reproduction.

However it seems that running pnpm nx vitest project1 does still leave zombie chromedriver and Google Chrome processes in the background. But running cd project1; pnpm vitest run does not, so I would say that this is an issue in nx rather than Vitest.

And even when nx leaves those Vitest processes in the background, the browser mode does no longer mess up the second cd project2; pnpm vitest run test run. Test cases of the zombie process are not interfering with the second run.

I don't see there anything that should be fixed on Vitest so let's close this issue. @dmaretskyi feel free to open new issue or comment here if you think otherwise. Thanks for the great repro and analysis!