Non-Empty Mistaken For Valid

What goes wrong

A read path or fallback chain only checks that a value is present, non-empty or truthy, never that it is valid. A present but invalid value — zero, a negative, an out-of-range list element, a hand-edited number — is passed on as an explicit valid choice instead of falling back to the default or being refused.

Example

The code only checks that a limit is set, so a stored limit of -1 passes the check and is used as a real limit.

Not to be confused with

A non-empty invalid value is treated as valid — not several empties folded into one (Empty states lose their meaning), not null elements inside a list (Container passes with null elements), and not a yes-or-no flag read by truthiness (Boolean Knob Read By Truthiness).

Discovered by

@sks24git GitHub

Field notes · 4

@sks24git2026-11-04beat 2 review rounds

After a failed create, a script asks "does this branch already have a pull request?" and the lookup also returns closed ones. An old closed request then reads as success, and the real error is dropped again.

Name the state you need in the lookup. A find-by-name call can fall back to closed records.
Make each guard rule fail alone in a test. A rule that only fails beside another is untested.

@sks24git2026-10-27beat 2 review rounds

A client treats a missing key as 'no data' but the server sends the key with a null value. The dashboard prints a fact line with an empty limit, and the unit test deletes the key instead of sending null.

Test the shape the server sends. Fixtures copied from real responses catch null versus missing.
Check absent and null together. A strict undefined test lets null through.

@sks24git2026-10-26beat 2 review rounds

A job picked the newest green nightly whose timing artifacts were listed, by name alone, never checking the expired flag. Past retention the download failed in every shard and the no-data fallback stayed unreachable.

Treat a listed artifact as absent until its expiry flag says so. A listing entry is not a file you can fetch.
Fire fallbacks on failure, not on empty input. A stale id is not an empty id.

@sks24git2026-09-07beat 3 review rounds

A run's reasoning level was stamped on its stats only when it finished. Every hunt that burned its budget and failed vanished from the depth-vs-findings table, so depth was scored on the sample where it could not lose.

Stamp run metadata on every exit path, not just success. The failures are the half of the table you built it for.