[miniflare] Fix Browser Run Windows race condition

[petebacondarwin]

Fixes the flaky Tests (Windows, packages-and-tools) CI failures observed in run 25108579707/job 73576107174, where 11 of 21 tests in packages/miniflare/test/plugins/browser/index.spec.ts failed even with { retry: 3 }.

When Miniflare launches Chrome for Browser Run bindings, it returns the WebSocket endpoint as soon as Chrome prints its DevTools listening on ws://... banner. On Windows the underlying listening socket is occasionally not yet accepting connections at that point, so the first request from workerd to Chrome fails with kj/async-io-win32.c++:281: failed: ConnectEx(): #1225 The remote computer refused the network connection.. The error propagates up through /v1/acquire as the response body Error: The remote computer refused…, which the user worker then fails to JSON-parse — the surface the test sees is SyntaxError: Unexpected token 'E', "Error: The"... is not valid JSON.

This PR addresses the issue at two layers:

1. Chrome readiness probe in launchBrowser (packages/miniflare/src/plugins/browser-rendering/index.ts). After waitForLineOutput resolves with the WS endpoint, probe Chrome's /json/version HTTP endpoint with retry/backoff (25ms → 250ms, ~5s total) until it accepts a connection. This addresses the root cause of ConnectEx (#1225).
2. Defense-in-depth retry inside the binding worker (packages/miniflare/src/workers/browser-rendering/binding.worker.ts). A new fetchWithConnectRetry helper retries on substring-matched transient workerd/kj errors (connection refused, remote computer refused, network name is no longer available, network connection lost, disconnected) and is applied to setSessionInfoRoute, #proxyRawWebSocket, and #proxyJsonRequest. This catches WSARecv (#64) and similar mid-fetch socket failures that the readiness probe alone cannot prevent.

The fix is internal — there are no API or behaviour changes for users beyond the elimination of the spurious connection errors. On macOS the probe succeeds on the first attempt, adding ~no measurable overhead (browser test suite still completes in ~9–10s locally over 4 consecutive runs).

• Tests

  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because: covered by current tests

• Public documentation

  • Cloudflare docs PR(s):
  • Documentation not necessary because: internal flake fix; user-visible impact is just that browser rendering bindings no longer fail with spurious connection errors during startup on Windows.

Additional testing:

Ran pnpm -F miniflare test test/plugins/browser/index.spec.ts four consecutive times locally on macOS — all 21 tests pass each time. The failure mode being fixed is Windows-specific and not reproducible on macOS/Linux without artificial fault injection.

---

[changeset-bot]

🦋 Changeset detected

Latest commit: 56293c3

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[workers-devprod]

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler

Show detailed file reviewers

[github-actions]

✅ All changesets look good

[ask-bonk]

I've now thoroughly reviewed all three changed files. Let me analyze the code for any actionable issues:

1. waitForBrowserReady (index.ts:251-290): The retry logic with exponential backoff is correct. The deadline-based loop, per-request timeout via AbortSignal.timeout, body draining, and error propagation via cause all look good. The URL construction on line 259 correctly converts ws:// to http:// before parsing.

2. fetchWithConnectRetry (binding.worker.ts:83-106): The retry logic is sound. The lastError variable on line 92 and the throw lastError on line 105 caught my eye — lastError could theoretically be undefined if maxAttempts is 0, but the default is 5 and the loop structure guarantees at least one iteration for any positive maxAttempts. On the last attempt (attempt === maxAttempts - 1), the error is rethrown immediately at line 99, so the throw lastError at line 105 is effectively unreachable dead code. This is not a bug, just defensive coding.

3. isRetryableFetchError (binding.worker.ts:62-71): The use of as cast is pragmatic for extracting the message from an unknown error type. The substring matching approach with case-insensitive comparison is appropriate for matching kj/workerd error messages.

4. RETRYABLE_FETCH_ERROR_SUBSTRINGS (binding.worker.ts:49-60): The "disconnected" substring is quite broad — but in context, this only triggers when fetch throws an error (not on HTTP error responses), and a fetch throw with "disconnected" in the message is indeed a transient connection failure. The breadth is acceptable for this defense-in-depth layer.

5. Changeset: Correctly scoped to miniflare as patch. Description is clear.

6. Integration points: The three call sites in BrowserSession (setSessionInfoRoute, #proxyRawWebSocket, #proxyJsonRequest) all correctly replace fetch with fetchWithConnectRetry with matching signatures. No call sites were missed — there are no other fetch calls to Chrome in this file (the loopback fetches to localhost are correctly left as-is since those go to workerd, not Chrome).

Everything checks out. The two-layer defense (probe + retry) is well-reasoned, the implementation is correct, and the change is appropriately scoped.

LGTM

github run

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 4 additional findings.

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@13734

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@13734

miniflare

npm i https://pkg.pr.new/miniflare@13734

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@13734

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@13734

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@13734

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@13734

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@13734

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@13734

wrangler

npm i https://pkg.pr.new/wrangler@13734

commit: 56293c3

[ruifigueira]

lgtm, but we should replace Browser Rendering with Browser Run.

[NuroDev]

Is this not the default?

[petebacondarwin]

I couldn't get format-on-save to work in VS Code because the extension couldn't find the binaries.
And this was a suggested workaround.
Not really relevant to this.

[workers-devprod]

Codeowners reviews satisfied