fix(tracing): remove discarded chunk files and temporary screenshots - #44089

Covers MCP run 43334601460 and tests 1 run 43334601362, both for head 1297bc00a5ae0480f8dfc226634e4a18fb91346e.

Caused by this PR

The five MCP tracing groups account for 33 failures. Context.stopTracing() calls tracing.stop() without a path after starting with live: true. That sends mode: 'discard'; the new _stopChunk() cleanup deletes the live .trace files that MCP and CLI return to the user. Preserve live trace files and their referenced resources when stopping live recording.

• mcp/cli-cdp.spec.ts:125 — tracing-start-stop over cdp: the returned .trace file is missing; Chrome, Chromium and Edge.
• mcp/cli-devtools.spec.ts:245 — tracing-start-stop: the returned .trace file is missing; all seven browser/platform jobs.
• mcp/tracing.spec.ts:21 — check that trace is saved with browser_start_tracing: the directory listing lacks the .trace file; all seven jobs.
• mcp/tracing.spec.ts:55 — check that trace is saved with browser_start_tracing (no output dir): the same missing file; all seven jobs.
• mcp/tracing.spec.ts:89 — browser_start_tracing traces isolated contexts: the alice trace is deleted, so finding its name returns undefined and path.join() throws; all seven jobs.
• library/browsercontext-reuse.spec.ts:315 — reuse launch › BC-079 should reset tracing: Chromium, Firefox and WebKit fail with Tracing is already stopping, including every retry. Dispatcher disposal starts discard cleanup without awaiting it; the new file-queue wait keeps _isStopping set when context reset calls Tracing.stop(). That call suppresses the first stop error, then _stop() throws again. Disposal and reuse must wait for the same pending cleanup.
• library/chromium/connect-over-cdp.spec.ts:231 — CD-007 should write traces to provided artifactsDir on connectOverCDP: stopChunk() without a path now deletes cdp-trace.trace, but the test still expects it to exist. This failure follows the intended non-live discard change; update that assertion to expect the trace file to be absent, while keeping the network/resource assertions.

Pre-existing flake / infra

These three groups are confirmed pre-existing Chrome crash-recovery failures, not newly introduced tracing failures. All three fail with the same errors on Linux Chrome in main run 43332112061, SHA c59cf2040091ece8b59f56dd59a6d0e9080a7dfd, which does not contain this PR:

• mcp/crash.spec.ts:31 — reports the navigation error, then resets and logs the crash: times out waiting for recovery.
• mcp/crash.spec.ts:58 — lists only one tab: timeout and Not connected.
• mcp/crash.spec.ts:79 — marks non-current crashed tab in the tab list: timeout and Not connected.

The refreshed CI history snapshot also shows each of these three tests failing in 20 unrelated Linux Chrome results since November 6. No group remains uncertain. This was source and CI-log inspection; I did not build or run the PR.

Covers tests 1 run 43334601362, head 1297bc00a5ae0480f8dfc226634e4a18fb91346e. The separate MCP report already has a verdict in the earlier comment.

Caused by this PR

• library/browsercontext-reuse.spec.ts:315 — reuse launch › BC-079 should reset tracing: fails on Chromium, Firefox and WebKit with browser._newContextForReuse: Tracing is already stopping, on the first attempt and all three retries. Disconnecting the reused context disposes TracingDispatcher, which starts discard cleanup without awaiting it. This PR makes discard wait for _fs.sync(), leaving _isStopping set when the next context reset calls Tracing.stop(). That method suppresses the overlapping stopChunk() error, but _stop() throws the same error. Context reset must await the pending tracing cleanup rather than start a competing stop.
• library/chromium/connect-over-cdp.spec.ts:231 — CD-007 should write traces to provided artifactsDir on connectOverCDP: fails on Chromium, including all three retries, because cdp-trace.trace is absent at line 253 (Expected: true, Received: false). stopChunk() without a path sends mode: 'discard', and the new _stopChunk() branch deliberately deletes this non-live trace. The trivial correction is to change that file-existence assertion to .toBe(false) and retain the network and resource assertions.

No failure in this run remains uncertain or is classified as a pre-existing flake. I inspected the CI logs and the exact PR source; I did not build or run the PR.

Covers MCP run 43340754804, head d6cb5329c65120062007082a03ad541db905900c. The merged report has eight failing test groups.

Caused by this PR

All five tracing groups have the same cause. Context._startContextTracing() starts with live: true; stopTracing() calls tracing.stop() without a path. The client sends mode: 'discard', and the new server cleanup deletes the saved live trace and its non-content-addressed files. Queuing deletion without waiting fixes the earlier context-reuse failure, but does not preserve live traces.

• mcp/cli-cdp.spec.ts:125 — tracing-start-stop over cdp: the returned .trace file is missing in all five applicable jobs: Chrome on macOS/Linux/Windows, Chromium on Linux, and Edge on Windows.
• mcp/cli-devtools.spec.ts:245 — tracing-start-stop: the returned .trace file is missing in all seven browser/platform jobs.
• mcp/tracing.spec.ts:21 — check that trace is saved with browser_start_tracing: the directory listing lacks the .trace file in all seven jobs.
• mcp/tracing.spec.ts:55 — check that trace is saved with browser_start_tracing (no output dir): the same missing file in all seven jobs.
• mcp/tracing.spec.ts:89 — browser_start_tracing traces isolated contexts: the alice trace is deleted in all seven jobs; finding its filename returns undefined, so path.join() throws.

Small fix: skip the new file-removal block in _stopChunk() when this._state.options.live is true. Preserve both the live .trace file and its referenced files; retain deletion for non-live discarded chunks. These tests check files returned to users, so changing their assertions would hide the bug.

Pre-existing flake / infra

These are confirmed pre-existing failures, not just suspected flakes. All three have the same errors in Linux Chrome main run 43332112061, SHA c59cf2040091ece8b59f56dd59a6d0e9080a7dfd, before either PR commit:

• mcp/crash.spec.ts:31 — reports the navigation error, then resets and logs the crash: 30-second timeout waiting for recovery at .toPass().
• mcp/crash.spec.ts:58 — lists only one tab: 30-second timeout and Not connected when listing tabs.
• mcp/crash.spec.ts:79 — marks non-current crashed tab in the tab list: the same timeout and Not connected.

The latest CI-history snapshot also records each crash test failing in 20 unrelated Linux Chrome runs. No group remains uncertain.

The same-head tests 1 run 43340754629 is green: the earlier context-reuse and CDP assertion failures no longer appear. Its two retry-rescued tests do not count as failures.

I inspected the PR source, CI logs and refreshed history snapshot. I did not build or run the PR.

Covers MCP run 43350307485, head 56d399ce91ef3698cbaaafb240af0c0b5288f2ac. The latest merged report records 3 failed, 5232 passed, 631 skipped.

The current diff preserves live trace files and their resources when discarding a chunk. It does not change the crash tests or the MCP crash-recovery code. No failure in this run is attributed to the PR.

Pre-existing flake / infra

All three failures occur in both the PR's Linux Chrome job and the Linux Chrome job on main, at c59cf2040091ece8b59f56dd59a6d0e9080a7dfd, which does not contain this PR:

• mcp/crash.spec.ts:31 — reports the navigation error, then resets and logs the crash: the same 30-second timeout at .toPass(), waiting for crash recovery.
• mcp/crash.spec.ts:58 — lists only one tab: the same 30-second timeout followed by Not connected at browser_tabs.
• mcp/crash.spec.ts:79 — marks non-current crashed tab in the tab list: the same 30-second timeout followed by Not connected at browser_tabs.

These are confirmed pre-existing failures, not a claim that retries will pass. No group remains uncertain. I inspected the source and both CI logs; I did not build or run the PR. The CI-history database refresh was blocked by the missing GITHUB_TOKEN, so the evidence above comes directly from GitHub Actions.