Port fix from vitejs/devtools#520: allocate standalone WebSocket ports atomically #206

Context

vitejs/devtools#520 ("fix(core): allocate standalone WebSocket ports atomically") by @webfansplz fixed vitejs/devtools#517 (parallel Vitest runs crashing with EADDRINUSE because the standalone WS port was probed-then-bound instead of bound atomically). Its diff was against packages/core/src/client-adjacent node code — packages/core/src/node/ws.ts — which no longer exists in vitejs/devtools: the v0.9 migration retired the bespoke WS server there in favor of this repo's initHub/WsRpcTransport.

The core fix already shipped here — #171 ("fix: atomically allocate standalone ws ports"), merged 2026-08-06, binds standalone WsRpcTransport servers to port 0 and lets the OS pick atomically. It's already included in the devframe@0.9.0-beta.2 that vitejs/devtools now depends on, so the EADDRINUSE race itself is resolved.

What's unverified is the other half of #520's diff: "publish the WebSocket endpoint and refresh remote docks after the port is resolved" — in the old ws.ts, once the atomic bind returned a port, the code rebuilt contextInternal.wsEndpoint and re-emitted dock:entry:updated for every registered remote iframe dock so their connection URLs picked up the real port. That responsibility now lives in this repo's hub-internals (getInternalContext / remote-dock token + WS-endpoint metadata, per vitejs/devtools's AGENTS.md) and @devframes/hub/client's connectRemoteDevframe/parseRemoteConnection — not in vitejs/devtools anymore.

Diff: https://github.com/vitejs/devtools/pull/520/files

For agents picking this up

• Read fix(core): allocate standalone WebSocket ports atomically vitejs/devtools#520's diff and DevTools opens a fixed-port (7812) WS server under Vitest, parallel monorepo test runs crash with EADDRINUSE vitejs/devtools#517 for the full root-cause writeup.
• Confirm fix: atomically allocate standalone ws ports #171 fully covers the atomic-bind half (it should — no action needed there).
• Check whether a standalone WsRpcTransport/hub instance that binds to an OS-assigned port (port: 0) correctly re-publishes its resolved WS endpoint to already-registered remote docks once bound, the way old ws.ts did with dock:entry:updated. If there's a gap — e.g. a remote dock registered before hub.ready resolves ends up with a stale/empty connection URL — fix it in packages/hub/src/node/initiate.ts or the relevant hub-internals path.
• Add a regression test mirroring the parallel-bind scenario from DevTools opens a fixed-port (7812) WS server under Vitest, parallel monorepo test runs crash with EADDRINUSE vitejs/devtools#517 if one doesn't already cover it.
• Credit @webfansplz as the original reporter/author: include a Co-authored-by: webfansplz <...> trailer (look up their GitHub noreply email, or omit if unavailable) and mention them in the PR description.
• Link back to fix(core): allocate standalone WebSocket ports atomically vitejs/devtools#520 and DevTools opens a fixed-port (7812) WS server under Vitest, parallel monorepo test runs crash with EADDRINUSE vitejs/devtools#517 in the PR description.
• Close this issue when done (or close it directly if you confirm no gap exists beyond fix: atomically allocate standalone ws ports #171).