In a long Cypress open-mode session, why do older Command Log snapshots stop restoring?

## The retention window Command Log time travel is paid for in browser memory. Every snapshot Cypress keeps is a detached copy of the page's DOM held in the tab running your tests, alongside the messages, URLs and console properties of each logged command. A spec with forty tests and a couple of hundred commands each would, kept in full, grow without bound over a working session. So Cypress bounds it. **`numTestsKeptInMemory` is the number of tests for which snapshots and command data are retained**, and as of Cypress 16 it defaults to **50** during `cypress open`. Test fifty-one does not stop being logged — the Command Log still lists it, still shows what ran and what passed — but the oldest test's stored data is released to make room. ## What "aged out" actually clears When a test falls out of the window, Cypress clears the command-log data it was holding for that test so the browser can reclaim it: - the **DOM snapshots** attached to each of its entries; - the entries' **messages and URLs**; - the **console properties** each entry would have printed on a click; - any other per-entry fields the runner accumulated for it. The effect is that the rows survive as a record while the *evidence behind them* is gone. That is the right trade for a long interactive session, but it is a genuine surprise the first time you scroll back an hour into a session and find the top of the log inert. ## What you see instead Hover or pin an entry whose snapshot has been released and the app tells you plainly. The preview stays on the live page and the toolbar reads **"The snapshot is missing. Displaying current state of the DOM."** The same note appears in the entry's console output if you click it. Two nearby cases produce their own distinct messages, and it is worth being able to tell them apart: | What you see | What it means | |---|---| | "The snapshot is missing. Displaying current state of the DOM." | the entry has no snapshot to restore — commonly because its test aged out | | "Cannot show snapshot while tests are running" | the spec has not finished; time travel is unavailable until it does | | A pin that vanishes when you press rerun | the snapshot named belonged to the previous run, so the pin is released | ## Diagnosing it in a long session The symptom people actually report is *"time travel stopped working"*, and it is almost never a bug. Work through it in order: 1. **Is the spec still running?** If the run has not finished, hovering will refuse and pinning will do nothing at all. Wait for the run to settle before blaming the snapshots. 2. **Which tests still restore?** If the recent ones restore and the early ones do not, that is the retention window doing exactly its job, not a fault. 3. **How long has this tab been open?** A session left running across many file saves has re-run the spec many times; each rerun starts a fresh log, and pins held over a rerun are released because they named snapshots from the previous run. 4. **Do you actually need the early tests?** Usually the fix is to narrow the run — an `it.only` or a single spec — so the failure you care about is inside the window rather than sixty tests behind it. ## Tuning the window, and what it costs The setting cuts both ways, and neither direction is free: - **Raise it** and you can scroll further back through a long spec, at the cost of holding that many more detached DOM copies in the tab. On a heavy application — a support-ticket queue rendering hundreds of rows with a rich component tree — that is where a tab that grows to gigabytes and eventually becomes unresponsive comes from. - **Lower it** and the browser stays responsive through hours of interactive work, at the cost of a shorter history. This is the right move on a machine that is already tight on memory, or on a spec whose pages are unusually large. - **Leave it alone** for most work. Fifty tests is a long way back, and the more common fix for "I cannot reach the failure" is to run less, not to remember more. ## The habit that avoids the problem Long open-mode sessions on a spec that fails intermittently reward a different rhythm: reproduce the failure with the smallest run that still fails, keep the browser tab fresh rather than nursing one open for a whole afternoon, and pin the entry you care about **while it is still recent** rather than scrolling back to it later. The snapshot you need is the one taken minutes ago, and the window is generous enough for that. What the window will not do is turn an open-mode session into an archive.