fix(fetch): do not crash on late EPIPE after refused body by Skn0tt · Pull Request #42116 · microsoft/playwright

Simon Knott (Skn0tt) · 2026-08-04T08:52:36Z

Fixes#42074. node:http has a footgun where socket.on('error') is bubbled up into request.on('error') while the request is ongoing. If the server decides not to read the request body in full, e.g. to prevent DoS, there is a race where it first responds 413, fulfilling the response and unlinking socket.on('error') from request.on('error'), and only after that the client receives an error while trying to finish writing its request body. This is an unhandled error event and crashes the host process.

The fix is to listen for the error event and swallow it if the race was detected. Axios fixed this race in axios/axios#10576, i'm looking into what got does now.

When a server answers without reading the request body and then resets the socket, Node can emit a late write EPIPE/ECONNRESET on the client socket. APIRequestContext does not listen for that, so the process dies. Fixes: microsoft#42074 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

github-actions · 2026-08-04T09:39:42Z

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

🔴 The failures are caused by this PR — by design

Eight of the nine failures are the new should not crash when server refuses body before reading it test this PR adds, failing on chromium, firefox and webkit. That's exactly what the PR sets out to prove: it's a repro-only draft with no fix yet, so red CI is the expected outcome. The lone unrelated failure (test-step.spec.ts:1728 on macOS) is a pre-existing flake.

Details

Caused by this PR

[chromium/firefox/webkit-library] › library/global-fetch.spec.ts:710 › should not crash when server refuses body before reading it (8 shards) — the new test added by this PR. It reproduces [Bug]: APIRequestContext kills the process on an unhandled request-socket ECONNRESET when a server refuses a body before reading it #42074: the server destroys the socket mid-upload, Node emits a late EPIPE/ECONNRESET on the request socket, and with no listener it becomes an unhandled 'error' that kills the process. There's no fix in the diff yet, so it fails everywhere — as intended. Not a flake: this (project_name, file, test_title) has 0 prior runs in the results DB, it's brand new.

Pre-existing flake / infra

[playwright-test] › test-step.spec.ts:1728 › show api calls inside expects (macos-latest-node22) — pre-existing flake. In the aggregated results DB this test failed 1 of 3876 runs, and that one failure was on an unrelated PR (feat(webkit): roll to r2331 #41783, sha 22abdad), same macos-latest-node22 bot — a SHA this PR can't be responsible for. The diff only touches tests/library/global-fetch.spec.ts, nowhere near the test runner's step reporting.

_{Triaged by the Playwright bot - agent run}

Listen for errors on the request socket and ignore network write errors once response headers have arrived, matching undici policy. Otherwise a server that answers (e.g. 413) without reading the body can leave an unhandled socket EPIPE/ECONNRESET and kill the process. Fixes: microsoft#42074 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

Remove the per-request socket error handler when the request closes and the socket is still alive, so keep-alive reuse does not accumulate listeners. If the socket is already destroyed, leave the handler for a possible late write EPIPE. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

Yury Semikhatsky (yury-s) · 2026-08-04T16:51:27Z


+ socket.on('error', handleRequestError);
+ request.once('close', () => {
+ if (!socket.destroyed)


Add a comment explaining why it has to be removed and only if !socket.destroyed.

Done in 4d0640d - kept the destroy check and documented why.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

github-actions · 2026-08-05T11:36:30Z

Test results for "tests 1"

7 flaky

⚠️ [chromium-library] › library/screencast.spec.ts:28 › screencast.start delivers frames via onFrame callback `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:495 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:299 › should report intercepted service worker requests in HAR `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:299 › should report intercepted service worker requests in HAR `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-page] › page/page-goto.spec.ts:90 › should work with Cross-Origin-Opener-Policy `@firefox-ubuntu-22.04-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:388 › should reveal errors in the sourcetab `@windows-latest-node22`

51230 passed, 1190 skipped

Merge workflow run.

github-actions · 2026-08-05T11:46:02Z

Test results for "MCP"

3 failed
❌ [chrome] › mcp/annotate.spec.ts:57 › should capture multiple screenshots in one annotation @mcp-windows-latest-chrome
❌ [chromium] › mcp/cli-save-as.spec.ts:41 › screenshot --hires @mcp-macos-latest-chromium
❌ [firefox] › mcp/annotate.spec.ts:137 › should abort MCP annotation when last screenshot is removed @mcp-windows-latest-firefox

8047 passed, 1284 skipped

Merge workflow run.

github-actions · 2026-08-05T11:49:18Z

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

🟢 CI is clear — all three failures are pre-existing flakes

The latest report (MCP run) has three failures, and none of them touch this PR's change. The diff only edits fetch.ts error handling on the API request path, while these are all MCP screenshot/annotation tests. Each one flips verdict across ~1700 runs on SHAs this PR can't be responsible for.

Details

The diff changes late-EPIPE/ECONNRESET handling in packages/playwright-core/src/server/fetch.ts plus a global-fetch.spec.ts test. That's the network fetch path — the MCP screenshot and annotation flows don't exercise it. All three failures landed on different browser/OS bots, which is the divergence pattern you'd expect from unrelated flakes.

Pre-existing flake / infra

[chrome] › mcp/annotate.spec.ts:57 › should capture multiple screenshots in one annotation (mcp-windows-latest-chrome) — bimodal in the results DB: failed 31 of 1750 runs on chrome, and it also flakes on chromium (2/1692), firefox (7/1666), webkit (6/1699) and msedge (1/441). Fails across ~30 unrelated PRs (41463, 41669, … 42132), so this PR isn't the cause.
[chromium] › mcp/cli-save-as.spec.ts:41 › screenshot --hires (mcp-macos-latest-chromium) — failed 1 of 1692 chromium runs, on an unrelated PR — a one-off flake on a test that otherwise passes everywhere (0 failures across chrome/firefox/webkit/msedge).
[firefox] › mcp/annotate.spec.ts:137 › should abort MCP annotation when last screenshot is removed (mcp-windows-latest-firefox) — bimodal: failed 3 of 1666 firefox runs, plus 1/1750 chrome and 4/441 msedge, on SHAs unrelated to this PR.

Of 56 failing runs for these three tests across the whole DB, only 3 are on this PR (one per test) — the rest are spread across dozens of other PRs. That's a flake fingerprint, not a regression.

For completeness: the earlier "tests 1" reports on this PR came back with only flaky (retry-rescued) results, no hard failures. The new global-fetch.spec.ts test this PR adds is passing now that the fix is in.

_{Triaged by the Playwright bot}

_{Triaged by the Playwright bot - agent run}

This comment has been minimized.
Sign in to view

Simon Knott (Skn0tt) changed the title ~~test(fetch): reproduce APIRequestContext crash on refused body~~fix(fetch): do not crash on late EPIPE after refused bodyAug 4, 2026

Simon Knott (Skn0tt) requested a review from Yury Semikhatsky (yury-s)August 4, 2026 09:52

Simon Knott (Skn0tt) marked this pull request as ready for review August 4, 2026 09:52

test(fetch): satisfy eslint curly in refuse-body regression
a839520
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) approved these changes Aug 4, 2026
View reviewed changes

Yury Semikhatsky (yury-s) mentioned this pull request Aug 4, 2026
fix(fetch): do not crash on a late request-socket error #42110
Closed

Simon Knott (Skn0tt) mentioned this pull request Aug 5, 2026
fix: do not crash on late EPIPE after refused body node-fetch/node-fetch#1910
Open

Simon Knott (Skn0tt)and others added 2 commits August 5, 2026 12:53

fix(fetch): comment keep-alive socket error listener cleanup
4d0640d
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

fix(fetch): shorten socket listener cleanup comment
b2a394c
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5cd1c251-bdcb-4f5f-b9a6-17ed643d095e

Simon Knott (Skn0tt) merged commit d5b1217 into microsoft:mainAug 5, 2026
45 of 48 checks passed

Navigation Menu

Uh oh!

fix(fetch): do not crash on late EPIPE after refused body - #42116

fix(fetch): do not crash on late EPIPE after refused body#42116
Simon Knott (Skn0tt) merged 6 commits into
microsoft:mainfrom
Skn0tt:skn0tt-fix-42074

Simon Knott (Skn0tt) commented Aug 4, 2026•
edited
Loading

Uh oh!

This comment has been minimized.

This comment has been minimized.

github-actionsBot commented Aug 4, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Yury Semikhatsky (yury-s)Aug 4, 2026

Uh oh!

Simon Knott (Skn0tt)Aug 5, 2026•
edited
Loading

Uh oh!

Uh oh!

github-actionsBot commented Aug 5, 2026

Uh oh!

github-actionsBot commented Aug 5, 2026

Uh oh!

github-actionsBot commented Aug 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Simon Knott (Skn0tt) commented Aug 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

github-actionsBot commented Aug 4, 2026

🔴 The failures are caused by this PR — by design

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Yury Semikhatsky (yury-s)Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

Simon Knott (Skn0tt)Aug 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actionsBot commented Aug 5, 2026

Test results for "tests 1"

Uh oh!

github-actionsBot commented Aug 5, 2026

Test results for "MCP"

Uh oh!

github-actionsBot commented Aug 5, 2026

🟢 CI is clear — all three failures are pre-existing flakes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Simon Knott (Skn0tt) commented Aug 4, 2026•
edited
Loading

Simon Knott (Skn0tt)Aug 5, 2026•
edited
Loading