Allure 2 backs its retry trend with a `retry-trend.json` file. What are the two numbers it stores for each build, and what is each one actually counting?

## The shape of the file `retry-trend.json` is a JSON array of trend points, newest first. Each point is the generic trend item shape Allure 2 uses for all its trend files: - `buildOrder` — the executor's build number for that report, when one was available. - `reportName` and `reportUrl` — where that point came from, so the rendered trend can link back. - `data` — a map of metric name to a whole-number count. What makes it the *retry* trend is the contents of `data`. The retry trend item initialises the map with exactly two keys and never adds a third: | key | what it counts | |---|---| | `retry` | attempts that were superseded by a later attempt in that build | | `run` | results that stayed visible in that build | ## How the two counters get their values This only makes sense in the light of what runs before it. The plugin that consolidates repeated attempts runs first: it groups the results, keeps the newest attempt of each group, and sets a boolean `retry` flag on every attempt it demotes. The trend plugin is registered immediately after it, so by the time the trend is computed that flag is already correct on every result. The trend plugin then does something the tree and summary plugins do not: it takes the **unfiltered** set of results, including the demoted ones, and folds each into the current point. The fold is a single branch — if the result carries the retry flag, increment `retry`; otherwise increment `run`. That is the whole computation. That choice of accessor is not incidental. Built on the filtered set, every result would look like a survivor and the `retry` counter would read zero on every build ever generated. Counting attempts is only possible from the population that still contains them. ## What the numbers do and do not mean Both counters are **counts of attempts**, and reading them as anything else is where this file gets misused. 1. **`retry` is not a count of tests.** One test retried several times contributes several. Many tests retried once contribute the same total. The file cannot tell those two runs apart, because nothing in it names a test. 2. **`run` is not the total number of executions.** It is the complement of `retry` within the same build, so the executions the runner performed are the two added together, not `run` alone. 3. **Neither counter looks at status.** A superseded attempt increments `retry` whether or not the outcome changed on the next attempt, and whether or not the visible attempt passed. 4. **A moving line has several innocent explanations.** The suite grew. The runner's retry allowance was raised. A slow environment pushed more tests into repetition for a day. The trend records how much repeated execution the build absorbed and nothing about why. Stated positively: this is a **workload** trend. It answers "how much of this build's execution was repetition?", which is a useful thing to watch precisely because it is cheap to compute and hard to argue with. It is not, and cannot be, a per-test signal. ## Where the older points come from The plugin does not recompute history. Older results are not present when a report is generated, so there is nothing to recount. Instead it reads the trend points that arrived with the parsed launch, computes one fresh point for the current build, puts that point at the front, and keeps the newest stretch of the list. Each generation therefore extends the series by exactly one entry, and every earlier entry is a value some previous generation computed and passed forward. One practical consequence: a report generated in a workspace that carried nothing forward produces a `retry-trend.json` with a single point in it. The line has not been reset by anything in the retry machinery — the plugin simply had no earlier points handed to it. The file is written twice per generation, once into the report's history data, which is the copy a later run can inherit, and once as widget data, which is the copy the rendered page reads. They hold the same list; they differ only in where the report keeps them.