[Bug]: 1.62.0 run-server hangs forever when multiple processes share one launchServer

[dunnbot]

Version

1.62.0

Steps to reproduce

A PHP test suite (Pest 5 + pest-plugin-browser) drives Playwright through playwright run-server --mode launchServer. Under parallel test execution, several worker processes connect to a single run-server instance.

1. Start playwright run-server --host 127.0.0.1 --port <port> --mode launchServer
2. Connect N worker processes (here 10) to that one server and drive browsers concurrently
3. Run a suite of 235 browser tests

Expected behavior

The run finishes, or a broken connection surfaces as an error. On 1.61.1 the identical suite completes in ~55s.

Actual behavior

On 1.62.0 the run reports most of its progress and then hangs permanently — no error, no timeout, no exit. Observed identically on a local macOS machine and on ubuntu-latest GitHub Actions runners, so it isn't environment-specific. The GitHub job had to be cancelled after 22 minutes of total silence.

Inspecting the stuck workers, every one holds a socket to the shared run-server port in CLOSE_WAIT:

php 79778 ... 14u IPv4 ... TCP 127.0.0.1:63154->127.0.0.1:63147 (CLOSE_WAIT)
php 79780 ... 14u IPv4 ... TCP 127.0.0.1:63163->127.0.0.1:63147 (CLOSE_WAIT)
php 79785 ... 14u IPv4 ... TCP 127.0.0.1:63155->127.0.0.1:63147 (CLOSE_WAIT)

The server end has closed, the client end never does, and the processes sit in state R — busy-spinning rather than blocking, which is why no timeout ever fires. Killing the run-server process does not release them; they keep spinning.

Separately, each run leaves its run-server process behind after the suite exits, so they accumulate across runs.

Bisect

Same suite, same test framework, same OS, only the playwright npm version changed:

Version	Result
1.60.0	passes, ~57s
1.61.1	passes, ~55s
1.62.0	hangs indefinitely

Confirmed A/B/A: reinstalling 1.62.0 reproduced the hang, and returning to 1.61.1 passed again.

Serial execution on 1.62.0 is unaffected — 235 tests pass in ~194s. The hang requires multiple clients against one launchServer.

Currently pinned to ~1.61.1 as a workaround.

[chenjiahan]

This issue is reproducible in Rsbuild after upgrading Playwright from 1.61.1 to 1.62.0: web-infra-dev/rsbuild#8202

The Ubuntu E2E job hangs near completion and eventually times out, while Windows passes.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at this.

This looks like a real regression in 1.62.0. Your A/B/A bisect is about as clean as it gets — 1.60.0 and 1.61.1 pass, 1.62.0 hangs, and reinstalling flips it back and forth — and there's now an independent second reproduction: rsbuild#8202 started hanging near the end of its Ubuntu E2E job after the same 1.61.1 → 1.62.0 bump. So I'm treating this as confirmed rather than trying to out-bisect you.

I wasn't able to stand up a fresh tip-of-tree repro in the triage environment (no browsers/build available here), so I'm leaning on your evidence plus a read of the server code rather than a run of my own. The one thing that would let a maintainer land a fix fastest: a minimal JavaScript repro — several browserType.connect() clients hammering one browserType.launchServer() (or run-server) endpoint concurrently — since the Pest/PHP harness is hard for us to run directly. If you've got that boiled down, drop it in.

What the symptoms point at

• The trigger is specifically multiple clients against one launchServer — serial execution on 1.62.0 is fine (235 tests, ~194s), so it's the concurrent-connection path, not the browser work itself.
• Server end has closed the socket (clients sit in CLOSE_WAIT), the client end never does and busy-spins in state R — so no client-side timeout ever fires. That reads like the server tearing a WebSocket connection down without a clean close being observed by the peer.
• One divergence worth recording: in rsbuild#8202 Ubuntu hangs but Windows passes; you see it on both macOS and Ubuntu. So it isn't purely OS-specific, but timing clearly matters.
• The leaked run-server process after each suite exit is likely the same root cause surfacing on shutdown (connections not fully released), rather than a separate bug.

What I checked

• Read the full thread including the rsbuild#8202 cross-report.
• Reviewed the 1.62.x server connection path (PlaywrightServer, WSServer, WebSocketServerTransport) for how shared-launchServer connections are accepted and disposed.
• Could not build a fresh tip-of-tree repro here (browsers not installed, build unavailable in this environment), so no independent ToT run — verdict rests on your confirmed A/B/A bisect and the independent rsbuild reproduction.

_{Triaged by the Playwright bot - agent run}

[dgozman]

Dunnbot (@dunnbot) This seems to be related to the change from #41712. The pest-plugin-browser does not use a public Playwright API, but instead sends internal protocol messages, and inevitably breaks whenever the protocol changes. This falls out of scope for Playwright, so closing.

[joshmanders]

Hey Dmitry Gozman (@dgozman) so Dunnbot is my AI assistant and posted this against my explicit rules. We're looking into a reproducible repo and if we can identify this is a pest issue handle it there and report back here.