---
name: rerun-carried-jobs-dedupe-executions
description: "Partial reruns copy untouched jobs into the new attempt with their ORIGINAL started_at — count executions by (run, box, started_at), never attempt rows"
metadata: 
  node_type: memory
  type: project
  originSessionId: 2f3777dc-c8aa-4f97-9970-8e5761283e1b
  modified: 2026-08-04T19:38:29.959Z
---

A GitHub partial rerun (`--failed` / `--job`) copies every untouched job into the new attempt as a row with its ORIGINAL `started_at` and carried conclusion. Listing jobs with `filter=all` therefore shows rows that never executed again: counting rows inflates BOTH numerator and denominator of any red-rate, and a carried `failure` reads as a fresh observation when it is the same single measurement (usher150-r2 attempt 2 showed Linux "failure" carried from attempt 1 — still exactly one Linux observation of that victim at that sha).

**Why:** rate claims (leg-red rate, flake rate) drove the USHER #150 milestone decision; an attempt-row count would have been confidently wrong in both directions. Measured by deployah 2026-08-04 over 15 golden runs: dedupe on (run, box, started_at) → Windows 13 red/21 executions (62%), Linux 2/19 (11%).

**How to apply:** when computing any per-leg rate or citing a rerun leg's conclusion, dedupe jobs on (run id, box, started_at); treat a carried conclusion as the SAME observation, not a repeat. A leg-red rate is still not a test-victim rate — classify each red job by FAIL-row presence before calling it a flake rate ([[failed-job-is-not-a-test-victim]]). Kin: [[gh-run-status-freezes]] (the run-level `status` field freezes too).

2026-09-09, #293 attempt 2, and it supplies THE TELL this entry was missing. The entry says a
carried job keeps its ORIGINAL `started_at` — true, and I used it — but it never says what a
carried job's `run_attempt` reads as. **It is RELABELLED to the new attempt number.** At
/attempts/2/jobs all five jobs reported `run_attempt=2`, including the three that never
re-executed. doyle read exactly that field and reported "all four attempt=2 with fresh starts,
none carried"; three of them were carried. The field looks like the discriminator, is the one a
reader reaches for first, and is identical between a fully-carried attempt and a fully-fresh one.

**THE DISCRIMINATOR IS `started_at` VERSUS THE ATTEMPT'S OWN `run_started_at`** (from
`/actions/runs/<id>/attempts/<n>`, or the run object once it is on attempt n): a job that started
BEFORE its own attempt began was copied into it. Measured here: attempt 2 `run_started_at`
00:14:32Z; traceability/changes/lint all started 00:11:0x–00:11:28Z with timestamp PAIRS byte-equal
to attempt 1's, so carried; both unit cells started 00:14:36Z, so fresh. One extra field answers it
and nothing else does.

**And the correction that ISN'T:** a carried success is still a TRUE observation OF THAT SHA — the
sha does not move across attempts of one run, so it counts as evidence FOR the sha. What it is not
is evidence that the rerun re-tested that job. Those are different claims and only the second one
fails. So the verdict here was unaffected (5/5 green at 9d718719 still gates) while the PROVENANCE
sentence was wrong, and the provenance is what a later reader mines for "how long does a full green
take on this chain" — they would have read a 4-minute sweep that never happened as one.

**How to apply, additive:** when reporting a rerun, state provenance per job in the form "N executed
in attempt <n> (hh:mmZ), M carried from attempt <n-1> (hh:mmZ), all at sha X". Never cite
`run_attempt` as proof of freshness. Kin: [[a-run-level-conclusion-is-not-an-attempts-verdict]]
(same family: the field that renders identically for a stale and a fresh reading).