[Bug]: Playwright Test for VSCode endlessly spawning 'node' subprocesses and overloading system memory on MacOS

[bdugg-91]

Version

latest

Steps to reproduce

1. Install Playwright Test for VSCode
2. Restart VSCode
3. Open MacOS Activity Monitor
4. Observe 'node' processes spawning and slowly filling system memory until crash

Expected behavior

Unnecessary node processes do not spawn, and system does not crash.

Actual behavior

node processes infinitely spawn and begin filling all available memory until system crashes

Additional context

No response

Environment

System:
    OS: macOS 14.7
    Memory: 212.03 MB / 16.00 GB
  Binaries:
    Node: 16.11.0 - ~/.nvm/versions/node/v16.11.0/bin/node
    Yarn: 1.22.21 - ~/.nvm/versions/node/v16.11.0/bin/yarn
    npm: 10.8.3 - ~/code/syndio/admincenter-fe/node_modules/.bin/npm
  Languages:
    Bash: 5.2.26 - /opt/homebrew/bin/bash

[mxschmitt]

I was not able to reproduce - do you mind sharing your project with us? Does it reproduce if you create a new project?

What is the output of 'ps aux | grep cli.js'?

[makker]

I'm experiencing the same issue. This started when I yesterday wanted to try out Playwright. Installed the NPM package with npm init playwright@latest and installed the VS extension (Playwright Test for VSCode v1.1.7). After few minutes Mac OS (Sonoma v.14.5) told that system is running out of application memory and I should close apps. Closing the applications doesn't help. OS will crash in few minutes and reboot and this starts again.

What seems to originally start the spawning of node processes is opening the Playwright Test for VSCode Test Explorer. Not sure if relevant, but the "loading..." status just stays there in the Test Explorer . See screen cap:

Finally I was able to kill all the node processes by remove the playwright config or the node_modules folder from the project. This removes the issue, but isn't of course permanent solution if i'd like to use Playwright. To reproduce the issue again just need to return the removed Playwright config and the node processes keep spawning and crash the system in minutes. The issue doesn't reproduce if I disable the extension before returning the files. But disabling extension doesn't help, if the processes have already started to spawn.

UPDATE: This issue reproduces if NVM default NodeJS version is 16.11.1, but I can't reproduce the issue if I change the default NodeJS to 18.20.3. I know latest Playwright does not support NodeJS 16, but crashing the OS should be fixed. IMO the NVM default version shouldn't affect Playwright. It should read the preferred NodeJS version from .nvmrc if possible, or maybe package.json's engines.node setting.

[bdugg-91]

That's interesting, I might try it again with an updated node environment. That's convenient if that fixes it as we're currently in the process of updating our project from node 16 to node 20 anyways.

[mxschmitt]

Playwright does not support Node.js 16 anymore as per https://playwright.dev/docs/intro#system-requirements.

@bdugg-91 can you reproduce this on a fresh project? We need something which we can run locally or reproduction steps in order to act on it.

[mxschmitt]

Closing as part of the triage process since it seemed stale. Please create a new issue with a detailed reproducible or feature request if you still face issues.

[bdugg-91]

My apologies for the delayed response. It's fine to close, it was definitely related to using node 16 and the issue was resolved by using a newer node version.

[makker]

So, users can't have Node.js version 16 as their NVM default if they want to use Playwright? Otherwise their OS (Mac) will keep crashing? How come Playwright gets to direct the user's default Node version? I understand that Playwright is not supported by Node 16, but is quite extreme letting systems crash without warning. How about preventing playwright running with unsupported node version and showing an error? Did you try reproducing the issue by having Node 16 as the NVM default?

[bdugg-91]

I believe they can still use Playwright with Node 16, the issue just seems to be with the VSCode Extension for what it's worth.