[microsoft-playwright-automation]

Concurrent runners delete the current transform-cache entry while another runner writes it. On Windows this can make an otherwise successful compilation fail with EPERM.

Preserve the current revision during cleanup. If writing a cache entry fails, log the error and continue with the compiled code without publishing that entry.

The new regression test injects failed map and code writes during ESM discovery. The existing clear-cache and sequential revision-cleanup tests cannot install this failure without changing their setup.

Verified the regression fails before the fix and passes afterward; all 66 cache/loader tests, npm run build, and npm run flint pass on Windows. A four-process stress run completed 12,187 shared-cache writes without an exception. No browser is involved.

Fixes: #43601

_{Prepared by the triage workflow.}

[github-actions]

Test results for "MCP"

1 failed
❌ [chrome] › mcp/request-blocking.spec.ts:69 › allowed works (origin) @mcp-macos-latest-chrome

5188 passed, 614 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

1 flaky

⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › VI-030 should work with video+trace `@chromium-playwright-x64-ubuntu24-64-core-node22`

23558 passed, 702 skipped

---

Merge workflow run.

[github-actions]

🟡 One CI failure remains uncertain

Hi, I'm the Playwright bot. I checked the PR changes, the failed job, and the updated CI test history.

Details

There is no clear evidence that #43616 caused the reported MCP failure, but I could not confirm a pre-existing flake either.

Uncertain — macOS/Chrome MCP

[chrome] › mcp/request-blocking.spec.ts:69 › allowed works (origin) timed out after 30 seconds; the log also reports MCP error -32000: Connection closed. There was no retry. Neither the log nor the report attachment identifies the underlying cause.

The PR changes compilation-cache cleanup and cache-write error handling, not MCP origin filtering. That compiler is shared by the test runner, so the diff alone cannot rule out an effect. The same test passed in all six other browser/platform configurations in this run; that is supporting context, not proof of a flake.

After refreshing the test-results database, the exact (chrome, mcp/request-blocking.spec.ts, allowed works (origin)) test had 589 macOS/Chrome runs on other revisions, all passing with no failed attempts, from September 30 through October 23. I found no failure of this test on an unrelated revision in any project, so it cannot be classified as a confirmed pre-existing flake.

Rerun the macOS/Chrome job. If it fails again, compare the PR revision with its base on macOS and capture MCP subprocess diagnostics to locate the stalled operation.

_{Triaged by the Playwright bot - agent run}