---
name: nextest-duplicate-fail-line-is-one-observation
description: "nextest prints a failure twice — live stream and final summary — and the second copy reads as a retry that confirms determinism; count PANIC occurrences, not FAIL lines."
metadata:
  type: feedback
---

A golden red was reported to me as "identical panic on the retry, so no rate argument needed" (releases#183, run 32341702157, 2026-08-20). There was no retry. The job log held **one** panic occurrence and **two** `FAIL` lines — same elapsed `56.001s`, same ordinal `( 20/183)` — which is nextest printing the failure in the live stream and again in its final summary block. And there was no retry policy to have produced one: zero `retr` matches in `.config/nextest.toml` or the workflow at that sha.

**Why:** two summary rows of one execution are indistinguishable from two executions if you count FAIL lines, and the duplicate is *more* convincing than a real repeat because the duration and ordinal match to the millisecond — exactly what a deterministic re-run would look like. The false conclusion is the flattering one: it retires the rate question, so nobody audits it. Cost here was near-zero only because the classification (structural-until-shown-otherwise for a first-ever-executed pre-declared cell) came from the CONTRACT and never needed a repeat — but the record would have carried a measurement that did not exist.

**How to apply:** count `panicked at` occurrences, not `FAIL` lines. Identical elapsed + identical ordinal ⇒ one execution printed twice; a real retry renumbers or re-times. Check the retry policy at the measured sha before calling anything deterministic — `grep retr` the nextest config AND the workflow. And when a peer hands you determinism as a supporting fact, it is a claim like any other: see [[dont-take-a-diagnosis-as-measured]]. Sibling for the cross-attempt version of this trap: [[rerun-carried-jobs-dedupe-executions]].