[Bug]: retain-on-failure produces truncated trace.zip files missing End of Central Directory record

[ashblox]

Version

1.59.1

Steps to reproduce

1. Configure trace: "retain-on-failure" with retries: 1 and a webServer in a Playwright config:

const config: PlaywrightTestConfig = {
  fullyParallel: true,
  retries: ci ? 1 : 0,
  use: {
    trace: "retain-on-failure",
    serviceWorkers: "block",
    navigationTimeout: 30000,
    actionTimeout: 10000,
  },
  webServer: {
    command: "pnpm start:mocked-auth",
    port: 3102,
    reuseExistingServer: !ci,
    timeout: 120000,
    stdout: "pipe",
  },
};

No custom context.tracing.start() / .stop() calls — trace collection is entirely config-driven.

2. Run a test that fails in CI on a resource-constrained or contended runner (in our case, an ARM64 GitHub Actions runner in a shared job alongside build/lint/unit-test tasks running via Nx with parallel: 3)
3. Inspect the resulting trace.zip files in test-results/

We cannot reproduce the truncation locally (Windows, x64, headed or headless). It only occurs in CI.

Expected behavior

trace.zip should be a valid, complete ZIP archive that can be opened in the Trace Viewer.

Actual behavior

trace.zip starts with valid PK local file headers but is truncated — the End of Central Directory (EOCD) record is missing. The file cannot be opened by any tool:

$ npx playwright trace open trace.zip
Error: End of central directory record signature not found. Either not a zip file, or file is truncated.

Both the initial run and retry produce independently truncated files of nearly identical size:

File	Size	Valid PK header	EOCD record
trace.zip (run 1)	75,121 bytes	Yes (50 4B 03 04)	Missing
trace.zip (retry 1)	75,222 bytes	Yes (50 4B 03 04)	Missing

The consistent ~75KB truncation point across both independent attempts suggests a systematic teardown cutoff rather than a random race. By manually walking the local file headers and inflating with zlib, we confirmed the trace data is partially present — action logs, route fulfillments, and fixture teardown events were all recoverable. The ZIP was simply never finalized.

This worked correctly on 1.58.x with the same config and CI setup.

Additional context

We run a second Playwright suite (E2E against a deployed environment) with the same trace: "retain-on-failure" config. That suite does not have retries enabled and its traces are always valid. The key differences in the failing (mocked) suite are retries, a webServer, and that it runs in a shared CI job with higher resource contention.

Suspected regression source

PR #39884 (commit a8ea6558, merged 2026-03-27) converted yazl/yauzl from static top-level imports to lazy await import() in the three codepaths that write trace.zip:

1. localUtils.zip() — the primary path for config-driven retain-on-failure traces
2. SerializedFS._performOperation('zip') in fileUtils.ts
3. testTracing.stopIfNeeded() / mergeTraceFiles() — final trace.zip assembly

The teardown flow wraps stopIfNeeded() in _runWithTimeout(...).catch(() => {}) — errors and timeouts are silently swallowed. The lazy await import('../zipBundle') adds async latency at ZIP creation time that did not exist in 1.58 (where the module was already loaded at startup). Under resource contention in CI, this could widen the window for the teardown timeout to fire after yazl has started streaming local file entries but before zipFile.end() completes writing the central directory and EOCD record.

A secondary area of change is the screencast/tracing refactor (PR #39512, PR #39520, PR #39937) which changed how screencast frames are captured during tracing. This could affect resource flush timing before ZIP assembly.

Environment

System:
  OS: Windows 11 10.0.26100
  CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  Memory: 4.51 GB / 31.80 GB
Binaries:
  Node: 22.22.0
  pnpm: 11.1.3
npmPackages:
  @playwright/test: 1.59.1 => 1.59.1

CI (where truncation occurs):
  OS: Ubuntu 24.04 (ARM64)
  Runner: GitHub Actions, 32 CPU / 128 GB
  Container: Playwright 1.59 image

[yury-s]

Can you try with the latest playwright (1.60.0) or even with @next?

[ashblox]

We have a 30-day adoption policy, but we discussed and will try updating to 1.60.0 on Monday, 6/8.

[artem-abridge]

We hit the same symptom on 1.59.1 (truncated trace.zip, valid PK 03 04 local headers, no EOCD) and chased it all the way down. Our trigger looks different from yours but produces the identical failure, so I think there may be more than one way to end up with an un-finalized merge — sharing data in case it helps.

Our trigger: Node.js 24 + a large trace entry (deterministic, reproducible offline)

Unlike your case (Node 22, ~75 KB files, CI-only, not reproducible locally), ours is:

• Node 24 (works fine on Node 20 / 22),
• triggered by a large per-context trace.trace (a flow navigating ~8 full pages → 6.1 MB uncompressed / ~2 MB compressed entry),
• 100% deterministic, reproducible locally and with no Playwright at all.

Root cause

mergeTraceFiles() re-streams each temp trace via the bundled yauzl:

inZipFile.openReadStream(entry, (err, readStream) => {
  zipFile.addReadStream(readStream, entryName);
});

playwright-core bundles yauzl 2.x, whose openReadStream decompresses by piping an fd-slicer read stream into zlib.createInflateRaw():

readStream.pipe(inflateFilter);   // fd-slicer Readable -> zlib InflateRaw

On Node 24 this pipe deadlocks for large entries — inflateFilter never emits end, so mergeTraceFiles never resolves. The worker is then torn down with the output zip half-written (entries present, central directory never written) → exactly the EOCD-less trace.zip we both see.

Isolation (Node 24, against the real failing trace):

path	Node 24
fd-slicer raw read (openReadStream(entry, { decompress: false })) drained directly	✅ completes (2,050,399 bytes)
zlib.inflateRawSync(buf) / createInflateRaw fed the whole buffer	✅ completes (6,116,501 bytes)
yauzl openReadStream(entry) (fd-slicer → inflate pipe)	❌ hangs forever

So it's specifically the legacy fd-slicer Readable → zlib transform pipe under Node 24's stream semantics.

Minimal repro (no Playwright)

// npm i yauzl@2.10.0 yazl@2.5.1   (yauzl 2.x pulls fd-slicer@1.1.0)
const fs = require('fs');
const yazl = require('yazl');
const yauzl = require('yauzl');
const ZIP = '/tmp/repro.zip';

const parts = [];
for (let i = 0; i < 60000; i++) parts.push(JSON.stringify({ i, s: 'x'.repeat(60) + Math.random() }));
const big = Buffer.from(parts.join('\n')); // ~5.8 MB -> deflates to ~0.77 MB

const zf = new yazl.ZipFile();
zf.addBuffer(big, 'big.bin');
zf.end(undefined, () => {
  zf.outputStream.pipe(fs.createWriteStream(ZIP)).on('close', () => {
    const t = setTimeout(() => { console.log('RESULT: HUNG'); process.exit(2); }, 15000);
    yauzl.open(ZIP, { lazyEntries: true }, (e, zip) => {
      zip.on('entry', (entry) => zip.openReadStream(entry, (e2, rs) => {
        let n = 0;
        rs.on('data', (d) => (n += d.length));
        rs.on('end', () => { clearTimeout(t); console.log('RESULT: OK ' + n); process.exit(0); });
      }));
      zip.readEntry();
    });
  });
});

Results:

• yauzl@2.10.0 + fd-slicer@1.1.0 — Node 24.16 → RESULT: HUNG; Node 22.20 / 20.20 → RESULT: OK
• yauzl@3.3.2 — Node 24.16 → RESULT: OK

Suggested fix

Bump the yauzl bundled in playwright-core to 3.x. yauzl 3.x reworked its stream handling (no longer the old fd-slicer pipe) and decompresses large entries correctly on Node 24.

Note on the relationship to the OP

Your repro is Node 22 with small ~75 KB files, which our large-entry/Node-24 deadlock cannot explain — so I suspect there are two distinct triggers of the same "merge never finalized → no EOCD" symptom: a timing/teardown-cutoff path (yours) and this hard yauzl-2.x deadlock (ours). A yauzl 3.x bump fixes the deadlock; separately, making the merge await its final outputStream → file flush (and not let teardown swallow it) would harden the timing path you described.

Workaround for anyone stuck on Node 24

Patching mergeTraceFiles to avoid the streaming pipe — read each entry raw ({ decompress: false }), zlib.inflateRawSync it, and re-add via addBuffer (with lazyEntries for sequential reads) — produces a valid trace in ~150 ms on Node 24. We're running this via pnpm patch until the bundled yauzl is upgraded.

Environment: @playwright/test 1.59.1 (and 1.60.0 — mergeTraceFiles is identical), Node v24.16.0, macOS.