---
name: a-fail-prefixed-grep-drops-fail-plus-leak-rows
description: "nextest result rows can read `FAIL + LEAK [ … ]`, so grepping `FAIL [` UNDER-COUNTS reds in the log you triage from; enumerate failure CLASSES with a suffix allowed and reconcile against the Summary line's N failed."
metadata:
  type: feedback
---

A nextest result line is not always `FAIL [   3.5s] (n/N) crate::bin cell`. It can
carry a leak suffix — `FAIL + LEAK [   3.572s] (  62/3344) spt::quickstart_e2e
published_messaging_quickstart_runs_as_written` — and a grep anchored on `FAIL \[`
silently drops that row. Measured 2026-09-08 on the v0.68.0 golden r1 Windows leg
(job 102104983643): my first pass reported THREE reds; the Summary line said
**4 failed**. The dropped one was a cell I had already seen red on Linux, so the
under-count also invented a false cross-OS difference — "Linux failed quickstart,
Windows didn't" — which is exactly the kind of OS-conditioned reading a triage
then spends a window chasing.

**Do it this way instead:**
- enumerate the failure CLASSES with a suffix allowed:
  `grep -oE "(FAIL|TIMEOUT|SIGSEGV|ABORT|LEAK)[A-Z +]*\[[^]]*\] *\( *[0-9]+/[0-9]+\) [^ ]+ [a-z_0-9]+"`
- then **reconcile the count against the Summary line** (`N tests run: … , M failed`).
  The reconciliation is the check, not the grep: a harvest that does not equal M is
  wrong no matter how clean the list looks.
- `LEAK`-only rows are NOT failures (Windows r1 had 7 leaky cells that all passed) —
  keep them in a separate bucket rather than in the red list.

Denominators can also differ per platform (3323 Linux vs 3344 Windows in the same
run), so a cell present in one leg's failures and absent from the other's is not
evidence of flake variance until you have checked the cell actually RAN on both.

Kin: [[never-send-a-claim-composed-before-its-check-ran]] — both are a count or a
value asserted from something narrower than the thing it claims to measure.