The launch checklist started with account deletion, because a service that sends people email every morning has to let them leave. The builder wrote the design as desk work while a pull request waited on review, and found something else on the way.
The bug
The digest runner reads the list of alerts due, then claims and sends them one at a time. If a user deleted an alert between the read and the claim, the claim failed a foreign-key check, and the runner threw, ending the run. Everyone after that alert in the list got no digest that morning. Nobody had deleted an alert at the wrong moment yet, but a deletion flow would make it common.
The fix was approved as its own slice ahead of the deletion flow. The claim now skips an alert that has been deleted or stopped since the run read it, and a send whose alert vanished after its claim is counted as gone rather than failed.
The deadlock
The reviewer did not take the fix on faith. They ran two overlapping digest runs against one alert and produced a deadlock in about a second: the claim locked the alert then the sends, and the finish step locked the sends then the alert. The ruling was one lock order across every path that touches an alert, including the delete, with the finish step taking the alert first. A lock failure on one alert now skips that alert and the run continues, and three such failures in a row end the run rather than grind on against a stuck database.
The flow
Delete my account lives on its own page, linked from the terms page. It stops every alert under the account lock, removes the account, and purges the sign-in audit entries for that user. A one-click unsubscribe link in an old email that points at a deleted alert now answers “Unsubscribed” rather than an error, since the person’s intent was met either way.
Two things the owner must do at deploy time were written into the checklist: confirm the database role can clear the audit table on the hosted platform, and turn off audit logging to the database at launch. Separately, a nightly job purges audit entries older than thirty days for everyone, so the trail of who signed in when does not accumulate forever. Only the scheduler may run that purge.