---
name: cargo-tests-failfast-hides-the-tail
description: "`cargo test --tests` STOPS after the first failing test BINARY, so every suite alphabetically after it never runs — the log ends and reads as if the sweep completed. Use --no-fail-fast."
metadata:
  node_type: memory
  type: feedback
---

`cargo test -p <crate> --tests` runs one binary per integration file and **halts the whole
invocation at the first binary that fails**. The suites after it — alphabetically — are never
executed, and **nothing in the output says so**. The log simply ends. There is no "skipped", no
count of unrun binaries, no non-zero tally distinguishing "3 failed" from "3 failed and 40 suites
never started".

**Measured 2026-08-19 (todlando, releases#170).** A sweep died in `attach_resize_capture` (a missing
fixture binary, not a real failure). I read the four reds it reported and started classifying them —
while `wanmsg.rs`, `inject_control_wedge.rs` and every other suite after `a…` had never run. The
change under test was a **message-delivery** change: the suites that actually covered it were in the
unrun tail. Re-running with `--no-fail-fast` surfaced two more failing suites the first run had
never reached.

**Why it is a silence trap and not a mere inconvenience:** the failure it hides is on the SAME side
as the failure it shows, so the visible reds feel like the complete picture and invite exactly the
wrong next move — triaging the four you can see instead of asking what did not run. It is the
[[gate-filters-read-as-absent]] shape at the binary level: a filter you did not know you applied.

**How to apply.** For any sweep whose purpose is COVERAGE (a pre-gate leg, a regression check, "is
anything else broken"), pass `--no-fail-fast` — the fail-fast default is for a tight edit loop,
where stopping early is the point, and it is the wrong default the moment you are trying to
establish that nothing else moved. Then reconcile: count the `test result:` lines against the number
of test binaries the crate has. If those two numbers disagree, your sweep is incomplete no matter
what the visible results say.

**And the companion, same session, same crate:** a *precondition* failure reads exactly like a
product failure. Three reds in `attach_resize_capture` were `prebuild the fixture binary: cargo
build -p mock-adapter --bin capture-player` — the test saying its rig was not set up. Building the
fixture turned them 5/5 green with no product change. Read the panic MESSAGE before classifying a
red; a suite that names its own missing precondition is not evidence about your diff.

Related: [[daemon-lib-tests-deadlock-on-live-host]] (the other "is this red mine?" trap on this
box), and the general discipline in [[dont-take-a-diagnosis-as-measured]].