-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zombie browser process from the prevoius run connects to vitest WebSocket endpoint #5165
Comments
Hello @dmaretskyi. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with |
Hi @sheremet-va , thanks for taking a look at the issue. I've added a github repository with the reproduction. |
Thanks for the reproduction. I'm testing it on my ArchLinux PC and indeed I can see (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 |
This seems very similar to #5056 (comment). 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.
This sounds like a good idea. Maybe Vitest should also log a warning when previous run's process is trying to connect. |
@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? |
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
andbench.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
System Info
The text was updated successfully, but these errors were encountered: