One deleted test record blew up an error message it had no business throwing. A dev on r/PromptEngineering, jeffbradshaw, dug into it and found a trigger checking the parent record’s state before allowing a delete. Problem: by the time the trigger ran, the parent was already gone, wiped out in the same cascade. No parent to check meant the trigger assumed the worst and blocked the delete, even on totally harmless drafts.
He’d seen this shape of bug before, or thought he had. A cascade delete removes the parent, a child-level trigger fires a beat too late, and now it’s staring at empty space where a record used to be. The instinct is to treat that empty space as an error state, because most of the time it is. This time it wasn’t. It was just timing. The parent existed a millisecond ago, the trigger’s check just missed the window.
The fix looked obvious. If there’s no parent to check, don’t block. He wrote it, tested it, the false alarm vanished. Deleted the test draft, no error, clean log. Case closed, right? That’s usually where this kind of ticket gets marked resolved and everyone moves on to the next thing in the queue.
Here’s the pattern break: he asked one more question before shipping. What was that check actually protecting? Not what was it currently doing (throwing a false positive on a harmless test record) but what was it originally built to stop. Turns out the missing-parent signal wasn’t just catching orphaned drafts, it was also the only thing stopping someone from deleting a locked record, the one state that’s supposed to be untouchable. Same signal, two totally different meanings, and his “fix” couldn’t tell them apart. From the trigger’s point of view, a deleted-parent cascade and a locked record being force-removed look identical: no parent found, block the delete. One of those is noise. The other is the entire point of the check existing.
Old way vs new way
Old way: patch the symptom. See the false positive, remove the check that’s throwing it, move on. Fast, satisfying, and dangerous if that check was doing double duty. This is the default move under deadline pressure too, since a red error in the log feels like the thing that needs fixing right now, and the check that’s throwing it feels like the obvious cause. Nobody stops to ask what else depends on that same line of logic, because the ticket says “fix this error,” not “audit this validation path.”
New way: test the opposite case before you ship. He tried deleting a locked record after his fix. It went through. Silent, no error, gone. The fix hadn’t just cleared a false alarm, it had quietly deleted a real protection right along with it. No warning, no failed test, nothing in the log to flag it. If he’d shipped without running that second test, the bug would have shown up weeks later as a support ticket from someone asking why a record that was supposed to be locked forever just isn’t there anymore, and by then good luck tracing it back to a two-line fix from a sprint ago.
That’s the whole lesson in one sentence: removing a false alarm doesn’t mean nothing was lost, it means you haven’t found what else that alarm was catching yet. A check that fires on the wrong case and a check that fires on the right case can look exactly the same from where you’re standing. The only way to tell them apart is to go looking for the second case on purpose, because it will not announce itself.
How to actually fix it (without deleting the real protection)
- 🔍 Before you touch the check, ask what else it might be guarding, not just what it’s currently misfiring on. Read the commit history or the code comments around it if you can, someone usually left a clue about why it’s there.
- 🧪 Test the case you’re NOT trying to fix. If a check blocks two different scenarios, deleting it for one has to be tested against the other, every time, no exceptions for “obvious” fixes.
- 🛡️ Move validation earlier. The real fix checked the record’s state before the parent got deleted, not after it was already gone. Order mattered more than the check itself, and reordering the validation solved both cases at once instead of trading one bug for another.
- ✅ Ship only after both cases pass: the false alarm is gone AND the real protection still holds. Write both as tests if you can, so the next person who touches this code doesn’t have to rediscover the lesson the hard way.
Two-line bug, two-day lesson. Next time a check throws a false positive, don’t just ask how you make it stop. Ask what else it’s stopping. Go run that test on your own codebase this week!
Frequently Asked Questions
Q: How do I know if a safety check is doing more than what it appears to?
Check the git history for why it was added , bugs usually have a story behind them. Before you remove or bypass any check, ask: “What was this actually protecting?” In the post’s example, the check started as “protect locked records” but ended up catching draft deletes too. That’s the kind of hidden duty a quick fix can accidentally destroy.
Q: What’s the safest way to fix a false alarm without nuking real protections?
Don’t remove the check , make it smarter. The post shows this: instead of “skip the check if parent is missing,” the real fix was “check the state before the cascade happens.” Find what the check is actually trying to prevent, then narrow the condition to catch only that case. Sometimes the cleanest fix is the most specific one.
Q: Will QA catch these silent failures for me?
Probably not in normal testing. A commenter ran into the same pattern with billing: a validation check was the only thing stopping double charges, but it sailed through QA because the happy path worked fine. QA tests features well , they don’t usually try “delete the thing that’s supposed to be permanent.” Write tests for what the check is actually *guarding*, not just the feature it guards.
Q: How do I verify a fix before shipping it?
After you fix the obvious problem, go test the scenarios the original check was protecting. In the post, the author tried to delete a locked record after the fix and watched it vanish silently. That’s when they caught it. Make it a pre-ship ritual: if this check disappeared entirely, what would break?
The fix that removes a false alarm can also remove the real one
by u/jeffbradshaw in PromptEngineering