Partial result reported as complete

What goes wrong

A step covers only some of its inputs, then emits a result shaped exactly like a full one. Items that were skipped, unreadable or never returned leave no field, flag or count behind, so the reader has nothing to notice. The reader relies on the shape of the output to mean the work was whole.

Example

A health sweep cannot read a handful of targets, skips them, and still returns a result marked as fully checked, so the untested targets are scored alongside the ones that really passed.

Not to be confused with

Not Unearned Completion Report, where the work was never attempted at all; here real work happens and only its coverage is overstated, with no marker distinguishing the covered part from the skipped one.

Discovered by

@sks24git GitHub

Field notes · 8

@sks24git2026-11-04beat 2 review rounds

A split job took the max over the parts that reported and called it complete, while parts that never ran stayed silent. A wide change then showed a measured value built from only half of it.

Count the parts that should report, not those that did. A skipped part's silence looks like nothing found.
Measure once over the whole input. Per-part coverage claims multiply edge cases.

@sks24git2026-10-27beat 4 review rounds

A generated ticket says 'the findings name no files' whenever none of the named files fall inside the parent's scope. The reviewer's file list sits a few lines below and contradicts the note.

Derive a note from the fact it names. Key 'no paths' on the path list, not a filtered view.
Read generated text beside its data. A sentence its data contradicts is a bug.

@sks24git2026-10-14

A total adds up several sources, and a source that fails to load counts as zero. When one source is down, the total says nothing is left to do while the work still waits.

Keep failed apart from empty. A source that errors is unknown, not zero.
Mark a total built on partial data. Otherwise it reads as complete and lies quietly.

@sks24git2026-10-13beat 4 review rounds

A list of skipped files is cut to a fixed length, with no total and no flag. Readers take the prefix as the whole list, and the rest of the unread code drops out of sight.

Ship a total and a truncated flag with any capped list. A bare prefix reads as complete.
Say in the text when a list is partial. Clients repeat what the text claims.

@sks24git2026-10-13

A health check skipped the items it could not read, yet still reported a full result. Those items then counted as failures, so the alert fired nonstop and a real failure looked like more of the same noise.

Report partial results as partial. A skipped case must read as neither pass nor fail.
Test the quiet state of every alert. One that never clears is already off.

@sks24git2026-09-27

A summary reader falls back to raw data when a row is stale, but a row deleted by retention is simply missing. A window older than retention then sums the few days left and shows them as the whole baseline.

Treat a missing row as its own case. A stale flag only sees rows that exist.
Gate summary reads on retention. A window older than it must read the raw data.

@sks24git2026-09-10beat 1 review round

A repair command restores the principal of a broken transfer and says nothing about the bonus leg and redemption the original carried. The operator sees success and the customer is quietly short.

Say what a repair does not restore. Silent partial recovery reads as full recovery to the only person watching.

@sks24git2026-09-06beat 3 review rounds

A dashboard used completion count as hit rate and summed partial usage as full spend. Operators saw healthy success and lower cost while failed measurements stayed hidden.

Define metrics at the data boundary. Reuse one denominator across every view.
Treat partial telemetry as unknown. Never present a partial sum as a complete total.