Skip to content

feat(test-runner): read last failed tests from --last-failed=<file> - #42995

Merged
Pavel Feldman (pavelfeldman) merged 1 commit into
microsoft:mainfrom
pavelfeldman:last-failed-input-file
Sep 29, 2026
Merged

Pavel Feldman (pavelfeldman) merged 1 commit into
microsoft:mainfrom
pavelfeldman:last-failed-input-file

Conversation

@pavelfeldman

@pavelfeldman Pavel Feldman (pavelfeldman) commented Sep 29, 2026 •

Copy link
Copy Markdown
Member

Summary

  • --last-failed=<file> reads the failures from the given last run file and never writes to it; the run fails if the file is missing or malformed. Without a path, --last-failed reads <outputDir>/.last-run.json.
  • Breaking: --last-failed-file is renamed to --last-run-output-file. It only controls where the last run file is written, same as PLAYWRIGHT_LAST_RUN_OUTPUT_FILE.
  • Relative paths are resolved against the current working directory.

@github-actions

This comment has been minimized.

@github-actions

Copy link
Copy Markdown
Contributor

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

🟡 The two VS Code extension failures are probably not caused by this PR, but I couldn't prove they're flakes

Both failures are webServer tests in the VS Code extension suite, and the second one failed with EADDRINUSE. The --last-failed change here only affects the CLI test path, which these tests don't use. I couldn't find this test failing anywhere else, so a re-run of the VSCode Extension job is the quickest way to confirm.

Details

Besides the two failures, the report has 5 flaky tests (passed on retry), and they're in areas this PR doesn't touch. The two real failures come from the VSCode Extension job of tests 1 at 6d8233b.

Uncertain

  • [default] › run-tests.spec.ts:1298 › should start webServer and run-tests.spec.ts:1329 › should start webServer with npx command — the first test run shows started → failed with no further output. The second one fails because its webServer process can't bind: Error: listen EADDRINUSE: address already in use :::42130 → Process from config.webServer was not able to start. That looks like a port collision, possibly with a server left over from the first test.
    • Why this is unlikely to be the PR: the diff changes LastRunReporter and its options, --last-failed [file] in program.ts, and testActions.ts. LastRunReporter is only created in runAllTestsWithConfig, which only the CLI test command calls. The extension runs tests through the test server, which doesn't go through that code. Nothing in the diff touches webServer startup or port handling.
    • Why I'm not calling it a flake: the test-results DB has no results for the VS Code extension suite, so I couldn't check this test's history. Separately, the VSCode Extension job passed on 17 of the previous 19 tests 1 runs I checked (the other 2 were cancelled) (main pushes and other PRs), so I have no evidence of this test failing somewhere this PR can't reach.
    • What would settle it: a green re-run of the VSCode Extension job on this SHA.

Triaged by the Playwright bot - agent run

@github-actions

This comment has been minimized.

Comment thread packages/playwright/src/program.ts Outdated
['--last-failed', { description: `Only re-run the failures` }],
['--last-failed-file <file>', { description: `Override the default path for the last-run JSON file used with --last-failed (default: <outputDir>/.last-run.json). Same as PLAYWRIGHT_LAST_RUN_OUTPUT_FILE environment variable.` }],
['--last-failed [file]', { description: `Only re-run the failures. Optionally takes a path to the last-run JSON file to read the failures from, use --last-failed=<file> form (default: the file last run is written to)` }],
['--last-failed-file <file>', { description: `Path to write the last-run JSON file to (default: <outputDir>/.last-run.json). Same as PLAYWRIGHT_LAST_RUN_OUTPUT_FILE environment variable.` }],

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--last-failed-output-file to disambiguate

return undefined;
try {
const lastRunInfo = JSON.parse(await fs.promises.readFile(this._lastRunFile, 'utf8')) as LastRunInfo;
const lastRunInfo = JSON.parse(await fs.promises.readFile(this._outputFile, 'utf8')) as LastRunInfo;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not call readFailedTests() here?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is gone now

`--last-failed=<file>` reads the failures from the given last run file
and never writes to it. The run fails when that file is missing or
malformed. Without a path, `--last-failed` reads
`<outputDir>/.last-run.json`.

`--last-failed-file` is renamed to `--last-run-output-file` and only
controls where the last run file is written, same as
`PLAYWRIGHT_LAST_RUN_OUTPUT_FILE`. Relative paths are resolved against
the current working directory.
@pavelfeldman
Pavel Feldman (pavelfeldman) merged commit 3456aa7 into microsoft:main Sep 29, 2026
41 of 43 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

Test results for "tests 1"

5 flaky ⚠️ [chromium-library] › library/browsercontext-page-event.spec.ts:173 › should work with Ctrl-clicking `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/inspector/cli-codegen-2.spec.ts:105 › cli codegen › should upload a single file `@chromium-ubuntu-22.04-node24`
⚠️ [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`

52401 passed, 1243 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

Test results for "MCP"

2 failed
❌ [firefox] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) @mcp-ubuntu-latest-firefox
❌ [firefox] › mcp/cli-core.spec.ts:57 › click link @mcp-windows-latest-firefox

8827 passed, 1480 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

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

🟢 The two MCP Firefox failures are pre-existing flakes

Both tests fail intermittently on main and on unrelated PRs. This PR only changes the test runner's --last-failed handling, which the MCP suite doesn't exercise.

Details

The latest MCP run at 32cb420 has 2 failures, both on Firefox. The latest "tests 1" report has only flaky tests and no failures. The diff touches lastRun.ts, tasks.ts, testRunner.ts, testActions.ts, program.ts, runner.spec.ts and docs. None of these are in the MCP server or CLI code paths.

Pre-existing flake / infra

Triaged by the Playwright bot - agent run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants