In ReportPortal, a second attempt of a test item arrives while a launch is running. What does `retryOf` link, and what happens to the earlier item's place in that launch?

## The two routes into a retry link ReportPortal treats a repeated execution as **two rows that get linked**, not as one row that gets overwritten. Measured against `service-api` 6.0.0, the linking has two modes and the client's request decides which one runs. 1. **Explicit.** The start-item request carries `retryOf`, a string holding the uuid of the item this execution is a repeat of. The server resolves that uuid to a stored item and links the pair directly. If the uuid resolves to nothing, it logs and falls through to the other mode. If it resolves to an item that is *already* a retry, or one that has already left the tree, the server logs and does nothing — there is nothing sensible to demote. 2. **Implicit.** No `retryOf` is sent. The server instead looks for **active** items sharing the new item's `uniqueId` and the same parent, and takes the one with the latest start time as the winner. Active has a precise meaning here: an item that still has a path and whose own `retryOf` is null — in other words, one still in the launch tree in its own right. Both modes converge on the same outcome, so a client that never sends `retryOf` still gets retry handling, just inferred rather than declared. ## What being demoted actually costs an item One item comes out of the exchange as the **main** item and the others are demoted. Three separate things happen to a demoted item, and they are worth keeping distinct because they fail in different ways: | change | effect | |---|---| | its path is cleared | it is no longer part of the launch tree, so it stops appearing where readers browse | | its launch link is cleared | it no longer belongs to the launch for queries that walk from the launch down | | its `retryOf` is set | it now names the main item, which is the only route back to it | Alongside those, the demoted item's **statistics and its issue are deleted**. That is the part people miss. It is not merely hidden from a view: its contribution to the launch's counts is actively removed, which is exactly why a launch containing repeated attempts does not report inflated totals. The row itself survives in storage; its arithmetic does not. Two flags then go up. `hasRetries` is set on the surviving item, and `hasRetries` is set on the `Launch` — the launch-level flag is exposed on the launch resource, so a consumer can tell that a launch involved repetition without walking any items at all. ## Flattening, not chaining A test executed several times could in principle produce a chain, each attempt pointing at the one before it. ReportPortal does not do that. On every retry event the existing links are re-pointed so that **every** superseded attempt names the current main item directly. The structure stays one level deep: a main item, and a flat set of retries hanging off it. That matters for anything reading the data. Finding all attempts of a test is a single lookup on the main item, not a walk of unknown length, and there is no risk of a partially-updated chain leaving an attempt pointing at another attempt that has itself been demoted. ## Attempts that never finished Because the demoted attempt is a real row and not a fragment of the survivor, it can be left in an unfinished state — the client moved on to the next attempt and never sent a finish for the one it abandoned. ReportPortal sweeps these when the main item finishes: every item whose `retryOf` names it and which is still `IN_PROGRESS` is stamped with the main item's final status and end time. Without that sweep a launch could sit with attempts that never resolve. ## The reading a consumer has to get right The consequence for anything downstream is that **there is no single answer to "what did this launch run?"** — there are two, and they differ: - Walk the launch tree and you see main items only: one row per test, totals that count each test once. - Query by the retry link and you see every attempt, including the ones whose statistics were deleted. An integration that pulls results out of ReportPortal has to say which of those it means. Reconciling a tree-derived count against an attempt-derived count and calling the difference a defect is the usual mistake; the two are measuring different populations by design.