Skip to content

chore(net): use native happy eyeballs instead of the manual implementation - #42240

Merged
Pavel Feldman (pavelfeldman) merged 1 commit into
microsoft:mainfrom
pavelfeldman:remove-happy-eyeballs
Aug 14, 2026
Merged

chore(net): use native happy eyeballs instead of the manual implementation#42240
Pavel Feldman (pavelfeldman) merged 1 commit into
microsoft:mainfrom
pavelfeldman:remove-happy-eyeballs

Conversation

@pavelfeldman

@pavelfeldmanPavel Feldman (pavelfeldman) commented Aug 13, 2026

Copy link
Copy Markdown
Member

Summary

  • Delete the manual RFC 8305 implementation (utils/happyEyeballs.ts); Node.js 20+ races connection attempts natively via autoSelectFamily, which is enabled by default.
  • Keep the dual-family DNS lookup as a standard lookup option (dualStackLookup in utils/network.ts): a family-agnostic getaddrinfo can miss ::1 for localhost (AI_ADDRCONFIG filtering, /etc/hosts mapping ::1 to ip6-localhost only), breaking localhost servers bound to a single family.
  • API request HAR timings now come from the standard socket lookup/connect/secureConnect events; __testHookLookup is adapted into the standard lookup option.

Fixes: #42193

Comment threadpackages/playwright-core/src/server/fetch.ts
Comment threadpackages/utils/network.ts
Comment threadpackages/utils/network.ts
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

Copy link
Copy Markdown
Contributor

Hi, I'm the Playwright bot and I took a look at the CI failures here.

🔴 One failure is caused by this PR

mcp/cdp.spec.ts:75 › should throw connection error and allow re-connecting fails on every MCP browser/OS (chrome, chromium, msedge × ubuntu/macos/windows). Switching the CDP transport to dualStackLookup changes the shape of a refused-connection error, so the assertion no longer matches. The other two MCP failures are a pre-existing flake and one uncertain one-off.

Details

Overall: the latest tests 1 report has no real failures (22 flaky, all rescued on retry). In the latest MCP report, the cdp.spec.ts group is a real, PR-introduced regression; the other two are not.

Caused by this PR

  • [chrome/chromium/msedge] › mcp/cdp.spec.ts:75 › should throw connection error and allow re-connecting (7 bots across ubuntu/macos/windows). The test asserts error: expect.stringContaining('connect ECONNREFUSED'). This PR points the CDP transport at dualStackLookup, which returns both::1 and 127.0.0.1 for localhost; with Node's default autoSelectFamily both attempts are raced. When the CDP endpoint is down, both refuse and Node raises an AggregateError — the received error is now "AggregateError: async initializeServer: …" instead of a string containing connect ECONNREFUSED, so the assertion fails on every platform. In the test-results DB this test has failed only on this PR (chore(net): use native happy eyeballs instead of the manual implementation #42240) — 2 runs, and passed the other 242, on no other SHA/PR, which is exactly what a freshly-introduced, deterministic regression looks like. To fix, match the aggregated message (assert on the nested .errors / a substring that survives aggregation) or preserve the single-address error shape for the refused case.

Pre-existing flake / infra

  • [chrome] › mcp/cli-test.spec.ts:23 › debug test and snapshot (mcp-ubuntu-latest-chrome) — pre-existing flake. It fails with an empty snapshot (Expected substring: "button \"Submit\"", Received string: ""), and the same failure also hit unrelated PR feat(test runner): cancel operations on test end via default abort signal #41707 (mcp-macos-latest-firefox) — a place this PR can't be responsible for. It doesn't touch any networking path this PR changes.

Uncertain

  • [firefox] › mcp/cli-config.spec.ts:130 › global config (mcp-windows-latest-firefox) — I can't prove this one either way. It timed out with an empty snapshot (Expected substring: "800x600", Received string: "") and has never failed before (0 of 753 prior runs), so I can't call it a flake by the same evidence I used above. But it exercises no networking path this PR changes, and its empty-snapshot signature matches the cli-test flake above, so infra noise is the likely story. A green re-run of that MCP job would confirm it's not the PR.

Triaged by the Playwright bot.

Triaged by the Playwright bot - agent run

@github-actions

Copy link
Copy Markdown
Contributor

Test results for "MCP"

8101 passed, 1311 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

Test results for "tests 1"

20 flaky⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/chromium/oopif.spec.ts:282 › should click `@chromium-ubuntu-22.04-node22`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-node22`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-node22`
⚠️ [chromium-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/global-fetch.spec.ts:293 › should return security details from response `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/har.spec.ts:639 › should have security details `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-page] › page/page-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node20`
⚠️ [webkit-library] › library/browsercontext-clearcookies.spec.ts:72 › should remove cookies by name regex `@webkit-ubuntu-22.04-node20`
⚠️ [webkit-library] › library/global-fetch.spec.ts:293 › should return security details from response `@webkit-ubuntu-22.04-node20`
⚠️ [webkit-library] › library/har.spec.ts:639 › should have security details `@webkit-ubuntu-22.04-node20`

51105 passed, 1208 skipped


Merge workflow run.

@pavelfeldman
Pavel Feldman (pavelfeldman) merged commit dffe620 into microsoft:mainAug 14, 2026
47 of 49 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Browser download retries do not reach IPv4 after an IPv6 TLS timeout

2 participants

@pavelfeldman@yury-s