2.1.0 Windows regression: process stays open due to open sockets

[AviVahl]

Project: https://github.com/wixplosives/mocha-pup

When upgrading to 2.1.0, tests started failing (timeouts) on Windows CI. Containers got stalled.

My tests execute a CLI which:

• runs webpack
• starts an http server
• launches puppeteer and opens a page.
• checks stuff in the page.
• closes the browser.

Debugging revealed the CLI process never shuts down, as there are two sockets left open:
https://github.com/wixplosives/mocha-pup/runs/413725670

Further investigation suggested it has to do with the browser connection.

Switching to pipe: true made it work. :o

Best guess: the WebSocket connection stays open and never gets destroyed.
Suspected PR: #5137 (it refactored Launcher.js, which has the connection setup)

Steps to reproduce

Tell us about your environment:

• Puppeteer version: 2.1.0
• Platform / OS version: Happens only on a CI which runs Windows Server 2019.
• URLs (if applicable): chore(deps): puppeteer@2.1.0 wixplosives/mocha-pup#1
• Node.js version: 12.14.1

What steps will reproduce the problem?
I wish it was that easy. :(
I couldn't reproduce the issue locally. I use Fedora 31, and only had Windows 10 at my office (where issue didn't reproduce). Issue happened consistently in every Windows CI run.

Please include code that reproduces the issue.
Apologies again. I'll try to create a smaller reproducible test-case.
(maybe a script that opens and closes puppeteer 10 times)

What is the expected result?
After calling browser.close(), no socket should stay open.

What happens instead?
Sockets get left behind, process never exits.

[AviVahl]

Still trying to get a smaller reproduction ready.
Meanwhile, I merged to master, with pipe: true, and opened a separate PR to see the issue:
wixplosives/mocha-pup#2

[nemchik]

I believe I may be affected by a similar issue. I have a process in place that works perfectly fine with 2.0.0 but when upgrading to 2.1.0 or 2.1.1 I see intermittent failures with various things I'm doing.

I confirmed with my project that the only change was the version of puppeteer. Do you think it would be possible to confirm that downgrading puppeteer to 2.0.0 resolves your issue?

P.S. I'm not a contributor to this project, just another user 😄

[AviVahl]

Downgrading to v2.0.0 consistently works. It is a v2.1.0 regression (which also occurs in v2.1.1).
Saw it making processes getting stuck in both GitHub Actions and Travis containers.

Meanwhile, all projects using puppeteer in our stack have switched to pipe: true, as we want the latest Chromium available.

[nemchik]

I'll see if I can rig up some testing with pipe: true to try and confirm this resolves the issue for me, but hopefully a more permanent fix can be found, or documentation added to explain why pipe: true would be needed in some situations.

[gczobel]

I'm using a library that uses puppeter and experience the same issue.
I forced puppeter@2.0.0 in my project and consistently works

[AviVahl]

Fixed by puppeteer@3.0.0 on my end. :)

I did have to add libgbm-dev to my linux ci for the new chromium version: wixplosives/mocha-pup@07b1d92#diff-353995fb5bebaef307ec25fa5be39042R19