feat(trace): split API requests into a separate network stream

[Devin Rousso (dcrousso)]

the existing .network stream mixed browser traffic with APIRequestContext traffic

record _apiRequest entries in .api.network, archive it as trace.api.network, and ingest it alongside .network

bump the trace format to 9 so older viewers reject traces that have the new stream

[Pavel Feldman (pavelfeldman)]

On a high level, I expect the fetch context to have its own trace file and its own network file. No apiNetworkFile in the recording state/ no version bump. API request context is just another context with its own trace and network.

[Devin Rousso (dcrousso)]

i did a bunch of digging and i think this is an even simpler approach as it just prevents API requests from being included in HAR while not doing anything to tracing

[github-actions]

Test results for "tests 1"

3 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:177 › serviceWorker(), and fromServiceWorker() work `@chromium-ubuntu-22.04-node20`
⚠️ [playwright-test] › ui-mode-test-progress.spec.ts:294 › should show live trace from hooks `@windows-latest-node22`

51186 passed, 1190 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

2 failed
❌ [chromium] › mcp/cli-route.spec.ts:19 › route-list shows no routes when empty @mcp-macos-latest-chromium
❌ [firefox] › mcp/cli-core.spec.ts:216 › dialog-accept @mcp-windows-latest-firefox

7970 passed, 1284 skipped

---

Merge workflow run.

[github-actions]

🟡 Neither failure is clearly on this PR, but I can't fully clear one

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

Two MCP tests failed in the latest run, both far from what this PR touches (it only splits API requests out of HAR recording in harRecorder.ts / harTracer.ts). The Firefox one is a known flake; the macOS one is a lone timeout I can't tie to anything, so I'm calling it uncertain rather than clean.

Details

Overall: the diff is confined to server-side HAR recording. Neither failing test exercises that path (one is page.route listing, the other a dialog prompt), so a causal link is hard to see. No failures in the tests 1 run — only flakes.

Pre-existing flake / infra

• [firefox] › mcp/cli-core.spec.ts:216 › dialog-accept <prompt> @mcp-windows-latest-firefox — pre-existing flake. Across the test-results DB this test failed 16 of 1540 firefox runs (~1%), spread over 9 distinct PRs, and passes everywhere else (0 failures on chromium/webkit/chrome/msedge). Unrelated to HAR recording.

Uncertain

• [chromium] › mcp/cli-route.spec.ts:19 › route-list shows no routes when empty @mcp-macos-latest-chromium — a plain Test timeout of 30000ms exceeded. This test has failed exactly once in 1565 chromium runs — and that once is this PR's own run, so I have no independent occurrence to prove it's a flake. The diff doesn't plausibly reach MCP route-listing, and a bare 30s timeout on macOS smells like infra, but per our own bar that's a hint, not proof. A re-run should settle it; if it goes green, this is noise.

_{Triaged by the Playwright bot - agent run}

[Pavel Feldman (pavelfeldman)]

I don't quite understand the logic that "enables" api requests when api request context is passed.

[Devin Rousso (dcrousso)]

this is to handle things like playwright.request.newContext().tracing.startHar() vs a "regular" BrowserContext (i.e. the latter will not include API requests in the HAR whereas the former will only include API requests in the HAR)

[Pavel Feldman (pavelfeldman)]

Also unclear why we would switch to fetch context in this case.

[Devin Rousso (dcrousso)]

note that this check existed before this PR

a standalone APIRequestContext emits these events directly, whereas for a BrowserContext they're emitted by the owned BrowserContextAPIRequestContext