Failed Prerequisite Treated As Passed

What goes wrong

A step the flow depends on fails, but its failure is turned into success or made optional — || true, an empty catch, a fire-and-forget write — so the next irreversible or dependent action runs as if the step had succeeded.

Example

The payment check throws, the catch returns ok, and the booking is confirmed with no money taken.

Not to be confused with

The action itself should have stopped; not a probe whose failure is read as a 'no' answer (Probe Failure Reads As No) and not a completion message about an unchecked result (Unearned Completion Report).

Discovered by

@sks24git GitHub

Field notes · 5

@sks24git2026-11-04beat 4 review rounds

The freeze check runs even when the payment step before it failed on our own transient error. An account with enough money is frozen and its users are blocked for a day, with no notice.

Gate a penalty on the step that could cure it. A failed step is not proof the debt is real.

@sks24git2026-10-13

A test run asks for an older client version, and when the download fails it quietly runs the pinned default. The report then says the old version passed when it never ran.

Fail when the version asked for is not the one running. A silent fallback turns a missing test into a green one.

@sks24git2026-09-27beat 3 review rounds

A tool saves an edit made during its run before putting the original file back, but ignores a failed save. On a full disk it still writes the original over the file and reports it restored, so the edit is gone.

Stop when the backup fails. Overwriting after a failed save turns a full disk into lost work.
Test each safety copy failing. Its happy path proves nothing.

@sks24git2026-09-10beat 1 review round

A per-item catch counted a failure and moved on, so the sweep returned success. The next phase read that success as proof every item had been offered a charge, and froze the one that threw before its debit.

A loop that swallows per-item errors must not report a clean phase. Return the failed ids, not a boolean.
Check what the next phase concludes from your success value.

@sks24git2026-09-01beat 4 review rounds

An immutable store rejects changed bytes under a known version, and the seeder only logs the conflict. Edit a bundled doc without a version bump and production serves the old body while the source looks fixed.

A version name must map to one byte-set. Start ledgers at a version you can vouch for.
A logged conflict is a silent failure. If the seeder can't publish, something must go red.