Skip to content

fix(chromium): only re-fetch replay-safe requests when reading response body - #42124

Merged
yury-s merged 2 commits into
microsoft:mainfrom
yury-s:fix-42002
Aug 4, 2026
Merged

fix(chromium): only re-fetch replay-safe requests when reading response body#42124
yury-s merged 2 commits into
microsoft:mainfrom
yury-s:fix-42002

Conversation

@yury-s

@yury-s yury-s commented Aug 4, 2026

Copy link
Copy Markdown
Member

Summary

  • Chromium sometimes evicts response bodies; response.body() fell back to Network.loadNetworkResource, silently issuing a real second network request for any resource, including requests that may have side effects on the server.
  • Only re-fetch requests that are safe to replay: GETs of static subresources (side-effect-free Sec-Fetch-Dest values) and prefetch requests (Sec-Purpose: prefetch, served from the http cache). Return an empty body otherwise.

Fixes #42002

Comment thread packages/playwright-core/src/server/chromium/crNetworkManager.ts Outdated
Comment thread packages/playwright-core/src/server/chromium/crNetworkManager.ts Outdated
@yury-s yury-s changed the title fix(chromium): do not re-fetch resources over the network when reading response body fix(chromium): only re-fetch replay-safe requests when reading response body Aug 4, 2026
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Test results for "tests 1"

8 flaky ⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@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:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/har-websocket.spec.ts:235 › should attach websocket messages `@chromium-ubuntu-22.04-node24`
⚠️ [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`
⚠️ [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:715 › should indicate current test status `@windows-latest-node22`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:827 › should update state on subsequent run `@windows-latest-node22`

51199 passed, 1188 skipped


Merge workflow run.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Test results for "MCP"

1 failed
❌ [chrome] › mcp/cli-storage.spec.ts:21 › state-save saves storage state to file @mcp-macos-latest-chrome

8049 passed, 1284 skipped


Merge workflow run.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

🟡 The one failure is very likely a flaky timeout, but I can't fully clear it

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

The only real failure in the latest reports is [chrome] › mcp/cli-storage.spec.ts:21 › state-save saves storage state to file (mcp-macos-latest-chrome) — a bare Test timeout of 30000ms exceeded. with no stack. This PR only touches Chromium's response.body() re-fetch path (crNetworkManager.ts), which the CLI storage-state test never exercises, so I don't think the diff caused it. But the only time this test has ever gone red is on this PR's own run, so I can't point to an off-PR failure to call it a confirmed pre-existing flake — hence yellow, not green.

Details

Overall: the earlier "cancelled" reports are incomplete (missing shards), so I looked at the latest reruns: tests 1 came back with 8 flaky, 0 failed, and MCP with 1 failed. Only that one failure needs a verdict.

Uncertain (leaning flake / infra)

  • [chrome] › mcp/cli-storage.spec.ts:21 › state-save saves storage state to file — a plain 30s test timeout, no error trace. Two reasons it's unlikely to be this PR:
    • The diff doesn't reach it. The change is scoped to Chromium response.body() re-fetch of evicted bodies in crNetworkManager.ts; this test writes storage state (cookies/localStorage) to a file and never reads a response body.
    • The test is rock-solid. In the aggregated results DB it's passed 623 of 624 runs on mcp-macos-latest-chrome, and 0 failures across every other bot. The single red is run 30944790620 — this PR's SHA 410f707a — and it went green again on the very next SHA (30945227797).
    • What keeps it from a clean green: the DB has no instance of this test failing on a SHA the PR can't be responsible for, so per our own rule I can't stamp it a proven pre-existing flake. A re-run of the MCP shard should settle it — I'd expect it to pass.

Flaky (within-run, already retried green)

  • The tests 1 report lists 8 flaky (video screencast, HAR websocket, COOP page tests, ui-mode-trace) — all rescued on retry and all in areas untouched by this diff. Nothing to triage there.

Triaged by the Playwright bot - agent run

@yury-s
yury-s merged commit 1f3818e into microsoft:main Aug 4, 2026
49 of 50 checks passed
@yury-s
yury-s deleted the fix-42002 branch August 4, 2026 21:55
Sign up for free to 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]: Tracing silently re-downloads resources via Network.loadNetworkResource, duplicating requests with side effects (Chromium only)

2 participants