Trial ID 14 was already taken. I did not know that until I had already overwritten it.
The feature I was shipping was an exit-feedback page for expiring trial teams. Instead of routing them to a Google Form on expiration, I wanted an in-house page: a short survey, a FeedbackResponses table, an admin report, and a deep-linkable preview tool for reviewing individual submissions. The page went up, the expiration emails pointed to it, the admin tooling rendered cleanly. The feature was done.
What I did not realize until later was that the provisioning step I had run earlier in the day had quietly overwritten a completely different production row.
The feature itself was clean
The public-facing piece is simple. An expiring trial team gets an email with a link to /exitfeedback.asp?token=<token>. They fill out a short form. The submission lands in FeedbackResponses. An admin page at /adminHTO/exitfeedback-admin.asp lists submissions and deep-links to individual previews.
Claude did most of the scaffolding under direction, and nothing about the page itself was surprising. The provisioning step is what bit me.
The assumption baked into the provisioning script
To wire the expiration email, I needed a row in the mailer configuration table. That table has an identity column. Claude drafted a provisioning script that used SET IDENTITY_INSERT to pin the row to ID 14.
The reasoning looked sensible. The script checked whether a row with ID 14 already existed; if it did, it ran an UPDATE, and if it did not, it ran an INSERT. An idempotent pattern, safe to re-run and free of duplicates.
The flaw was that the check answered the wrong question. It answered “does a row with ID 14 exist?” not “does this row belong to the mailer I am trying to provision?” On prod, a row with ID 14 had been there for months. It was the Staff Reminders mailer, the one that sends staff their weekly digest.
The script saw an existing row, ran the UPDATE, and replaced the Staff Reminders configuration with the exit-feedback configuration. It raised no error and no warning. The idempotent pattern had done exactly what it was designed to do, just on the wrong row.
How close it came
I found out because I checked the mailer table after the provisioning run and noticed the row name did not match. It said something about exit feedback where it should have said Staff Reminders.
I pulled the backup. I found the original Staff Reminders row there and used those values to reconstruct it.
The Staff Reminders mailer runs on a weekly schedule, and when I found the corruption, the next send was hours away. Every staff member on the list would have received an exit-feedback campaign in its place, sent from the same infrastructure with no alert firing. The mailer machinery has no concept of what a row is supposed to say. The exit-feedback feature would have appeared fine from every dashboard, staff would have gotten survey emails instead of their weekly digest, and anyone chasing the complaint would have had no obvious path back to that morning’s provisioning run.
I caught it before that send, but only because I checked the table as a matter of habit, not because I suspected anything.
What the check should have been asking
Any script that provisions a row by identity should verify the row’s content, not just its existence. Before overwriting, read the name, the marker, whatever field distinguishes “this is the row I own” from “this is some other row.” If the check fails, halt and surface the discrepancy.
The script I landed on reads WHERE designNotes LIKE '%exit-feedback-mailer%'. If a row with that marker exists, update that row. If it does not, insert without specifying an ID and let the database assign one. The numeric ID becomes an artifact of insertion order, not a hardcoded assumption about what is free.
“Row ID 14 exists” and “row ID 14 is mine” are not the same question. I know that now because I had to restore the Staff Reminders mailer from the backup and rebuild the provisioning script around a designNotes marker that the original script never bothered to check.