chore(trace): use a single id for calls and test runner steps

[Dmitry Gozman (dgozman)]

Summary

• The client instrumentation now assigns the protocol message id, so an api call and its test runner step share a single id. Metadata.stepId is gone; the id is minted in one place, the client connection, and only when nothing assigned one.
• Ids are minted with a random 3-character prefix per client connection, so that ids of different clients do not clash when they end up in a single trace.
• stepId is no longer written to the trace. Since v9 shipped in 1.63, this is a new trace version 10: traceV9 is frozen as a self-contained copy of the shipped format, and _modernize_9_to_10 rewrites the ids of older traces on the fly. TraceModernizer also owns client-side stacks via appendStacks().
• TraceModel merges actions by call id, so nonPrimaryIdToPrimaryId goes away.
• ClientSideCallMetadata.id becomes a string — the language ports need to send the message id there instead of an int.

Design choice

This is done to unify ids between steps and actions. Alternatively, we could use the callId as a step id, except for expect calls where the step is created much earlier than the call is made, and rewriting the id is too late.

[github-actions]

🔴 The one failure looks caused by this PR

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

reporter-html.spec.ts:756 › merged › trace should not hang when showing parallel api requests fails, and it exercises exactly the trace call-id merging path this PR rewrites. The other five results are flaky (passed on retry), so there's nothing to triage there.

Details

Caused by this PR

• [playwright-test] › reporter-html.spec.ts:756 › merged › trace should not hang when showing parallel api requests — this test renders a trace with four parallel API requests across two request contexts and clicks the resulting GET actions in the actions tree. That's the precise scenario this PR reworks: TraceModel now merges actions by call id and nonPrimaryIdToPrimaryId is gone, and TraceModernizer rewrites ids on the fly. Concurrent api calls sharing/duplicating a call id are where that merge logic is most likely to collapse or reorder actions. History backs this up: across the aggregated results DB the test's final verdict was passed in 1992 of 1992 runs (0 failures, 0 retry-rescues) between 2026-07-16 and 2026-08-27 — it has never failed or flaked on any other SHA. A test that green for ~2000 runs and turns red the first time on a PR touching its exact code path is a caused-by-PR signal, not a flake.

Pre-existing flakes / infra (not triaged)

• The five ⚠️ entries — library/video.spec.ts:664, library/chromium/chromium.spec.ts:179, library/popup.spec.ts:260, page/page-emulate-media.spec.ts:144, ui-mode-test-update.spec.ts:202 — all passed on retry and don't touch client instrumentation, trace ids, or the trace model. Unrelated to this PR.

Worth a look before merge: run the trace test locally against the parallel-request scenario and confirm the merged-by-call-id actions still resolve for concurrent API calls.

_{Triaged by the Playwright bot - agent run}

[github-actions]

🟢 The failures are all pre-existing flakes — this PR looks clear

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

The four reds are all MCP tests, each on a single browser, and none of them touch the trace call-id path this PR rewrites (client instrumentation, connection, dispatcher, TraceModel, protocol). Every one has a documented history of failing on other PRs on the exact same project, so I'm calling all four pre-existing flakes. Nothing here to triage.

Details

Pre-existing flakes / infra

Verdict flips across unrelated runs for all four, on the same (project, file, test) that failed here (aggregated results DB):

• [firefox] › mcp/cli-core.spec.ts:262 › click button with CSS selector (@mcp-windows-latest-firefox) — firefox: failed 5 of 716 runs, passed 711, across 3 distinct PRs (2 rescued on retry). Chromium/msedge/webkit never fail it.
• [firefox] › mcp/cli-keyboard.spec.ts:19 › press (@mcp-windows-latest-firefox) — firefox: failed 2 of 716 runs, passed 714, across 2 distinct PRs. Green on every other browser.
• [msedge] › mcp/annotate.spec.ts:349 › should annotate when context has no fixed viewport (@mcp-windows-latest-msedge) — msedge: failed 3 of 713 runs, passed 710, across 2 distinct PRs; also flakes on chrome/firefox. Not engine-specific to this change.
• [webkit] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) (@mcp-ubuntu-latest-webkit) — webkit: failed 3 of 730 runs, passed 727, across 3 distinct PRs; broadly flaky (chromium, firefox, msedge fail it too, several rescued on retry).

None of these exercise trace call-id merging, and each has failed on SHAs this PR can't be responsible for — the signature is flake, not regression.

_{Triaged by the Playwright bot.}

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "tests 1"

5 flaky

⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@chromium-ubuntu-22.04-arm-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@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:827 › should update state on subsequent run `@windows-latest-node22`

51359 passed, 1247 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [chrome] › mcp/output-max-size.spec.ts:22 › evicts oldest evictable files before write exceeds cap, pinned session.md survives @mcp-macos-latest-chrome

8326 passed, 1371 skipped

---

Merge workflow run.