A retried Cypress test left three images in cypress/screenshots — which is the last attempt?
answer
- Each failed attempt captures its own image
- The first attempt carries no suffix
- Suffixes start at the second attempt
- One suffix means retries, another means collisions
- overwrite only affects the numeric counter
basics
~20 sCypress appends (failed) to a failure capture and (attempt 2), (attempt 3) and so on to every attempt after the first, so the image carrying the highest attempt number is the attempt that finally ended the test.
solid answer
~40 sWith `retries.runMode` set to 2 a failing test runs three times, and each failed attempt takes its own failure screenshot. Cypress builds the filename from the suite and test titles, appends ` (failed)` for a failure capture, and appends ` (attempt N)` for every attempt after the first — the first attempt carries no attempt suffix, the second says ` (attempt 2)`, the third ` (attempt 3)`. So the highest number is the final attempt, and the one whose failure actually ended the test. A separate ` (1)`, ` (2)` suffix means something else entirely: it is the duplicate-name counter, added when a file of that name already exists, and suppressed by `overwrite: true`.
go deeper
Know that a retried test can leave several images and that the filename, not the timestamp, tells you which is which.
Explain how the name is assembled: base title, then the failed marker, then the attempt number, then the duplicate counter.
Show how you triage from the folder alone: which image to open first, what a difference between attempts tells you, and why yesterday's images are gone.
Decide how much retry evidence a pipeline keeps and in what shape, so a reviewer can tell one flaky test from a genuinely broken one.
## Why there are three files Test retries turn one failing test into several runs of the same test body. With `retries.runMode: 2` a support-ticket queue test that keeps failing in CI is attempted three times, and the automatic failure capture fires on **each failed attempt** — Cypress takes it whenever a test finishes with an error, not once per test. Three failed attempts, three PNGs. A test that fails twice and then passes leaves two images, not three: the passing attempt produces no failure screenshot. ## How Cypress builds the name The name is assembled in this order: 1. **The base name** — the name you passed to `cy.screenshot()`, or, when you passed none, the suite titles and the test title joined with ` -- `. 2. **` (failed)`** — appended when this is the automatic capture taken because the test errored. 3. **` (attempt N)`** — appended when the attempt index is greater than zero, with `N` being the human-readable attempt number. The first attempt gets nothing, so the suffixes start at ` (attempt 2)`. 4. **` (1)`, ` (2)`, …** — appended only if a file of that exact name already exists on disk, unless the capture ran with `overwrite: true`. For `describe('ticket queue') > it('filters by status')`, three failed attempts leave: | File | What it is | |---|---| | `ticket queue -- filters by status (failed).png` | first attempt | | `ticket queue -- filters by status (failed) (attempt 2).png` | second attempt | | `ticket queue -- filters by status (failed) (attempt 3).png` | third and final attempt | All three sit in `cypress/screenshots/<spec file>/`, under the spec path with the segments shared by every spec stripped out. ## The two suffixes people confuse - **` (attempt N)`** is about **retries**. It comes from the attempt index of the running test, and it applies to manual captures too: a `cy.screenshot('queue-open')` inside a retried test writes `queue-open.png` on the first attempt and `queue-open (attempt 2).png` on the second. - **` (1)`** is about **name collisions**. Two captures with the same resolved name in the same run produce `name.png` and `name (1).png`. It says nothing about which attempt they came from. That difference matters when you are triaging. Three files ending ` (attempt 1)`, ` (attempt 2)`, ` (attempt 3)` are one test retried; three files ending `.png`, ` (1)`, ` (2)` are one test that captured three times. ## What `overwrite` does, and what it does not `overwrite` defaults to `false` and can be set per call or through `Cypress.Screenshot.defaults({ overwrite: true })`. With it on, a capture whose resolved name already exists **replaces** that file rather than gaining a numeric suffix. It does not collapse retry attempts. The attempt suffix is part of the base name, so each attempt still resolves to a different filename and all of them survive. If you genuinely want one image per test regardless of retries, you have to name the capture yourself and accept that the last attempt to write it wins. ## Reading the folder in a CI job A practical order of operations when you have nothing but the archived folder: - Sort by name, not by timestamp. The attempt suffix is the reliable ordering; file mtimes on a runner can be rewritten by the archive step. - Open the highest attempt first. That is the failure the run reported; the earlier ones tell you whether the failure looked the same every time. - Compare attempt 1 against attempt 3. A queue that renders differently on each attempt points at state left behind by the previous attempt rather than at the assertion that failed. - Remember the folder holds only this run: `trashAssetsBeforeRuns` emptied it before the run started, so there is nothing from yesterday's failure to compare against unless the job archived it.
- A retried test passed on its third attempt. How many failure screenshots are on disk?Two — one for each failed attempt. The automatic capture fires only when a test finishes with an error, so the passing attempt writes nothing. You will see the base name and ` (attempt 2)`, with no ` (attempt 3)` file.
- Does `cy.screenshot('queue-open')` inside a retried test overwrite itself on each attempt?No. The attempt suffix is applied to manual captures too, so you get `queue-open.png`, then `queue-open (attempt 2).png`. Even `overwrite: true` keeps them apart, because it only suppresses the numeric duplicate counter, not the attempt suffix.
saying these in an interview costs you the question
- Reads the file without a suffix as the final attempt
- Confuses the (1) counter with a retry number
- Expects retries to overwrite one screenshot
- Thinks a passing retry also writes a failure image
- Assumes older runs' images are still in the folder