04 / 08
Restoring a document would have deleted its labels.
Found before a line of code was written. One feature, two screens and a button.
npx halfcycle A shared piece of code wipes every label and puts back whatever it is handed. The design handed it an incomplete list.
Would a code review have caught it?
Unlikely. Nothing fails and nothing errors. The loss turns up weeks later, somewhere else in the product.
Users can give a document extra names, labels and aliases, so it turns up when they search for it by the word they actually use. The search index keeps a row for each one, and a shared helper rebuilds those rows. Its method is blunt: delete every label row for the document, then insert whatever it is handed.
That is a perfectly reasonable helper, provided whoever calls it hands over the complete list. The restore design called it with only part of the list, the labels it could work out from the restored text. Everything a user had added by hand would have been deleted and never put back.
So restoring a document would have quietly made it worse. The restore itself succeeds. No error, no failed request, nothing in a log. The loss turns up weeks later in a different part of the product, when somebody searches for a document by the label they gave it and it is not there. By then nobody connects it to a restore they did last month, if they remember doing one at all.
Tests of the restore feature would not catch it, because they check that the text came back, and it did. The behaviour that destroys the labels lives in a third file that the design only called. Seeing it meant opening that file and reading what the function does, not what its name suggests it does.
Read the other seven, or the same argument in general terms: why an agent reviewing its own work is not enough.