Unknown answered as a definite result

What goes wrong

A value that is missing, empty, or not yet determined is folded into one of the definite outcomes the code already knows how to return. The caller then reads that outcome as a measured fact, when the only truthful answer was that the state could not be established.

Example

A readiness check finds no recorded outcome for a required step and reports the step as passed, so the release continues over a step that was never actually run.

Not to be confused with

Not missing field silently takes default, where an absent input falls back to a legitimate configured value; here the code manufactures a verdict about a state it never observed.

Discovered by

@sks24git GitHub

Field notes · 8

@sks24git2026-11-05beat 4 review rounds

A consent prompt read any typed reply that was not an edit as a final no. A user who asked a question about the post lost it, and the agent was told never to ask again.

Count only a clear decline as a no. A question is not an answer.
Pair every catch-all rule with what it must not catch. Final rules turn small misreads into lost work.

@sks24git2026-11-05

A wait loop treats an empty list of declared fonts as "this page has no fonts" and stops at once. When the stylesheet has arrived but is not parsed yet, the list is empty for a moment, and a good page fails.

Do not read "none yet" as "none at all". Check what you already know was sent before you stop waiting.
Blame a spent budget only if the wait used it. Else the message points at the wrong page.

@sks24git2026-11-01

A filter accepts only the values on its short option list, and a saved link names a value that fell off that list. The filter drops it without a word, and the page shows every row as if it were the filtered answer.

A dropped filter must never look like an applied one. Accept any value the owner really has, or say the filter was ignored.

@sks24git2026-10-30beat 1 review round

A fix for a stuck queue let unreachable recipients count as delivered. When every recipient was unreachable, the item was marked done with nobody having read it, and the alert vanished.

Count real deliveries before you close an item. Skipping the dead ones must not leave zero.
When you relax a done-rule, test the case where it fires for everyone.

@sks24git2026-10-27

A resume step read 'row says stop, no label' as a human lifting the stop. The label is posted after the row and can fail, so a lost post looks like an answer: the escalation is wiped and its retry cancelled.

Never read absence as an answer. A missing flag also means the write never landed; check the pending marker first.
Snapshot before retry proves nothing. Re-read state after the write.

@sks24git2026-10-26beat 1 review round

A helper derives a ticket's risk class from its items, and the caller passed none, so a frozen lane got the default class and its own lint rejected every ticket. Findings there can never be filed, and the run only exits.

Feed a classifier its real inputs. An empty list makes it answer the default, and the default fails the gate downstream.
Lint what you generate, per class. One template, every lane, in a test.

@sks24git2026-10-26beat 1 review round

A filter excluded a run only when three conditions all held, but one column was empty on every row written before it existed. Empty makes the whole test unknown, the row vanishes, and old failed attempts stop counting.

Wrap a NOT over nullable columns in a default. Unknown is not false, and NOT unknown drops the row.
Test the rows that predate the column. A migration's first day runs on them.

@sks24git2026-10-17

An unknown rule covers steps that add or remove a flag but misses the busy path that swaps one flag for another. Under load the gap reads as a firm no, so one input passes when idle and fails when busy.

Treat a swap as a remove plus an add. A rule that checks each alone misses it.
Test the fallback path under load. That is where answers flip.