Repository navigation
[Feature]: Ability to merge Playwright reports from the main run and --last-failed flag #33094
Description
🚀 Feature Request
In my CI/CD structure, I first run a certain scope of tests, and then I have the option to rerun failed tests using the --last-failed flag.
I would like to have the ability to merge the report from the full scope with the one generated by the --last-failed run.
Ideally, the tests from the --last-failed report would be treated similarly to retries in the merged report. This would mean having a new tab or section in the summary report, showing the failed tests as if they had been retried in a regular run.
Example
No response
Motivation
Currently, when using the --last-failed flag, Playwright generates a separate report for the rerun tests, which makes it harder to get a complete picture of the test outcomes. Combining the main report with the --last-failed results would provide a unified view, similar to how retries are displayed, improving test analysis and making it easier to track the progress of failed tests.
This feature would be especially useful in CI/CD pipelines, where developers often rely on reports to quickly assess the overall health of their tests and identify issues. Merging these reports would streamline the process, reduce confusion, and save time.
Activity
dgozman commentedon Oct 14, 2024
OSnuszka I'd recommend the
retriesfeature instead of--last-failed. The latter is aimed for the local development workflow. You can also look into merging reports, but it won't be the "same as retries" treatment.OSnuszka commentedon Oct 17, 2024
Thanks for the recommendation! I’m already merging reports (my automation setup splits them into shards/blobs), and I use
--last-failedafter a full test run to rerun tests at a later time, which helps mitigate issues related to environment stability, etc. I also use retries, but --last-failed is crucial in my automation structure and really supports continuous test runs.On that note, it would be great if you could also consider the feature request I submitted regarding merging the
--last-failedreport with the main report. This would allow a clearer view of test outcomes, similar to how retries are handled in reports, and would really streamline things for CI/CD pipelines. It would provide a unified view, making it easier to assess test health and track the progress of failed tests.dgozman commentedon Oct 17, 2024
OSnuszka Thank you for explaining your workflow, it sounds very interesting! What happens if you merge
--last-failedreport with a regular one today? I'd think everything should work, but last-failed tests will not be treated as retries, but rather as separate tests. Is there anything else not working in this scenario? I'd like to better understand the shortcomings to frame this feature request.OSnuszka commentedon Oct 17, 2024
Dmitry Gozman (@dgozman) I've just tested it, and it looks like a test that failed in the first run but passed with
--last-failedcreates two separate records in the report after merging the blobs. I see one record for the failed test and another for the passed one in the report. Is there something I can do to work around this, or would it require a feature request to address?dgozman commentedon Oct 17, 2024
OSnuszka Thank you for confirming. That's the expected behavior, there is no workaround today.
RemigiuszDudek commentedon Nov 1, 2024
OSnuszka as a kind of a work-around you can use allure-reporter - with this reporter, when running tests with
--last-failedflag, the newest tests replace previous runs. So the information about the failures is lost (if you want to retain it, you can always produce both reports), but there are no duplicated tests as in playwright report.Though I agree that it would be nice to have a flag for
merge-reportscommand specifying what should be done when "duplicated" test is encountered during merging process:overwrite- newer test replaces the older executionas-retry- keep newer execution as if they were simple retriesseparate- keep two runs as separate test execution (current behaviour)Here is how the comparison of both reports looks like:
OSnuszka commentedon Nov 12, 2024
Remigiusz Dudek (@RemigiuszDudek) Thank you very much for the suggestion and the detailed expansion of ideas for report merging parameters – it’s a really practical approach! I’ve used Allure before with other frameworks, and it certainly offers a lot of options, but for Playwright, I prefer to stick with the default reporter. Currently, we're at a stage in our projects where the Playwright reporter fits best, especially considering the complexity of our CI/CD setup and the code itself. From my experience, Allure can sometimes introduce complications, especially when updating the framework – I’ve had mixed results with it in Cypress.
Thanks again for the idea!
sattukishore commentedon Nov 15, 2024
I too have this use case where I want to run all failed tests at the end on my CI machine. last run reports(failed tests) are replacing main run reports even if I want to merge them. OSnuszka how did you merge main run and failed run reports?
Chr3is commentedon Jul 7, 2025
OSnuszka We have the same requirement:
2.1 download metadata & previous blob report for this job
2.2 if we have metadata for this job, we had a previous run -> run command with --last-failed
2.3 merge previous blob with the retry blob-report
2.4 upload metadata & merged report to artifactory (which replaces the previous report)
Expected:
The merged report does not duplicate the tests, which where invoked with --last-failed. It should be possible to
lraghavan-point commentedon Oct 21, 2025
Is it possible to bump up the priority on this feature request?
areebmohammed commentedon Apr 29, 2026
Hi, I'd like to implement this. Based on the discussion here, the core issue is that when merging a blob report from a last failed run with the original run's blob report, duplicate test entries are created rather than the results being reconciled, which makes it hard to get a unified view of test health in CI/CD pipelines.
My proposed approach would be to add a merge strategy flag to the merge-reports command with three modes, as outlined by Remigiusz Dudek (@RemigiuszDudek) above:
separate — current behavior, keep both executions as distinct records
overwrite — newer execution replaces the older one
as-retry — treat the newer execution as a retry of the original, consistent with how retries are displayed in the HTML report today
The default would stay as separate to preserve backward compatibility.
A few things I'd like to confirm before starting:
Is merge-reports the right place for this flag, or would it make more sense to configure this behavior in playwright.config.ts?
For as-retry mode, should the retry count in the merged report reflect the actual retry index, or just append as the next retry regardless of the original retries config?
Is there a canonical way tests are identified as "the same test" across two blob reports — is it by test ID, full title, or file + title combination?
Happy to open a draft PR once the approach is confirmed.
arham766 commentedon Jul 7, 2026
Ran into this too, and I think the implementation surface is smaller than it looks. The duplicate records come from the id-collision handling in
packages/playwright/src/reporters/merge.ts: when two blobs contain the sametestId,_mapTestIddeliberately salts the second occurrence into a new distinct id (internString(testId + this._salt)), so a--last-failedrerun of the same test necessarily shows up as a separate record.That makes
--merge-strategy(as sketched by Remigiusz Dudek (@RemigiuszDudek) and areebmohammed above) implementable at exactly that collision point, without touching the blob format:separate(default) — current salting behavior, fully backward compatibleas-retry— on collision, reuse the original id and renumber the incoming results'retryindices to follow the existing ones; the HTML report already knows how to render a result list with retries, so the unified view falls out of existing renderingoverwrite— reuse the id, keep only the newer resultsThe main design question left is ordering: "newer" needs to be well-defined across blobs (report metadata timestamp rather than filename sort), which matters for both
as-retrynumbering andoverwrite.areebmohammed if you're still on this, happy to leave it with you — your plan looks right to me. Otherwise I'd like to pick it up: Dmitry Gozman (@dgozman) would you be open to a PR along the lines above (flag on
merge-reports, defaultseparate)?areebmohammed commentedon Jul 7, 2026
Shahrier Islam Arham (@arham766) thanks for digging into the salting logic — that's a clean way to frame it. I'd like to keep working on this if that's alright, I already have context on the collision handling and want to see the --merge-strategy approach through.
Dmitry Gozman (@dgozman) would you be open to a PR along these lines, before I continue working on this?
arham766 commentedon Jul 7, 2026
Of course — it's yours, go for it. You had the claim first and the context; glad the salting analysis is useful, feel free to fold any of it into the PR. Happy to review or give the
--merge-strategybehavior a spin on Windows once you have something up.pavelfeldman commentedon Oct 31, 2026
We're closing all
P3-collecting-feedbackissues and retiring the label. #43813 explains why. This doesn't mean the request is wrong. If it still matters to you, please open a new issue against the latest Playwright version with your concrete use case and link back here.