Why this matters
The bug. The author intended to scope the UPDATE to the same predicate used by the INSERT above. Without WHERE, the UPDATE applies to every row in orders — including newly-created ones still meant to be active.
The fix. Mirror the predicate from the INSERT, or scope by the freshly-inserted archive ids. Better still: linters like pg_safeupdate (Postgres) or --safe-updates (MySQL) refuse statements that lack WHERE on UPDATE/DELETE. Turn them on.
War story. GitLab's 2017 production database wipe started with one engineer running a maintenance UPDATE and watching every row in the table change at once. Different specifics, same shape.
Review heuristic
Read every schema definition asking: what's the smallest set of values this field actually means? If the schema admits more than that — wrong types, out-of-range numbers, extra unknown fields — the validation is leaky.
External reference: CWE-20: Improper Input Validation.
↳ GitLab DB wipe; CWE-862.