I wonder if a manual safety here would've helped. There is this idea in the gun world that a gun has multiple safeties, like a trigger safety, striker safety etc, disassembly safety, disconnector safety, ...
And the way they are presented is in a way that they stack. But they don't.
Let's say the striker safety has failed and you drop the gun. It goes off. Even if you have a trigger safety. Or a disconnector safety.
Not in this case. There are many different kinds of safeties, and they aren't magic off switches.
Consider a computer program (with a UI mated to underlying mechanics) that talks to a database.
In this case, just because the frontend (the trigger) has a "safety" on it such that it guards against initiating a chain of events that results in something being written to the database, the backend generally remains capable of it anyway.
So, if you have some other logic or condition that can start that API call (let's assume the program fires off a bunch of random inputs to various APIs if you physically drop the computer it's running on, and then you drop it), the DB write may still happen even though it was never triggered from the frontend.
Now, you can do various things to guard against that known behavior- from ensuring the activity chain started on the frontend to physically disconnecting the computer from the database until you're ready to write- but at the end of the day the machine has to be capable of performing the write immediately when commanded, and the sacrifices you're going to make to enable that will be controlled by your engineering and testing.
In this case, the trigger (and other associated safeties) are the "frontend", the mechanical workings are the "backend", and "the gun fires" is "a DB operation".
And the way they are presented is in a way that they stack. But they don't.
Let's say the striker safety has failed and you drop the gun. It goes off. Even if you have a trigger safety. Or a disconnector safety.