mutated × unstructured — blows up live on input you didn't expect
Runtime Errors
A chain: unstructured input with no contract is mutated into state the code has no handler for, then crashes downstream. The hallmark: it works in dev and explodes on the first unexpected input, live.
Unvalidated input written into program state becomes an illegal value, and the program throws the moment it is used.
In the wild
Structural Invalidation
The data shape is wrong — types drift, properties vanish, slots stay uninitialized.
A function that sometimes returns nothing, used as if it always returns a value.
State mutated to a new type that the next reader does not expect.
An attribute set on only some code paths, read on a path that assumes it always exists.
A function's mutable default is shared across calls; one caller seeds it with a wrong-typed value, and a later caller crashes operating on it.
A collection assumed to hold one shape gains an element of another type -- directly or because a method mutated one item -- and the consumer crashes when it reaches the odd one.
Computational Exhaustion
The math or scale is broken — loops run away, indexes overrun, formulas hit a wall.
A counter advanced one step too far indexes past the end of the array.
An average over input that can be empty drives the denominator to zero.
An accumulating loop with no cap on input size turns a linear scan into O(n²) — fine in dev, fatal on real volume.
Float math yields NaN or Infinity, which crashes the first consumer that needs a finite number.
A size computed by multiplying or incrementing wraps past the integer max to a tiny value; the allocation looks fine, then an in-range-looking index writes off the end.
Architectural Drift
The contract is severed — an external API, library, or payload no longer matches.
Trusting an external payload's shape, then mutating local state from it.
A mixin reaches for a method a dependency upgrade quietly renamed or removed.
A payload reconstructs an object of an unexpected shape; the code mutates it as the type it assumed, and crashes on the first attribute that isn't there.
An upgrade renames the config key the code still reads directly; the service boots fine and dies on the first request in the new environment.
A record serialized by an older class version is rehydrated by a mixin/ORM that blindly sets whatever attributes the payload names -- so a renamed or dropped field lands on the new object and a later access breaks.