After deleting a board, nobody could add a new one
Adding a site failed with a bare Validation error once any board had been deleted. A deleted board still held its code, and the error named nothing.
You retire a board from the list, because the lease ended. Next week you add a new one, and the screen says “Validation error”. That is the whole message. It does not say which field, which rule, or what to change.
This was live on production. It was found not by a user but while repairing the system’s test suite, and the log does not record that anyone had hit it. But the effect is plain: after any board had been deleted, adding another one failed, and nothing told the person why.
What was actually going on
Deleting a board in this system does not remove its row. It marks it deleted and keeps it, which is how you keep history for invoices and photographs. A deleted board therefore keeps its site code.
The site code has a rule that no two boards can share one. That rule knows nothing about deletion. And the two routines that hand out the next code looked only at boards that were still live. So they found the highest live code and gave out the next one, which a deleted board was still holding. The database refused, correctly.
The refusal then vanished into a bad error message. The database library reports every failed rule as the same two words, “Validation error”, naming neither the field nor the rule. That is why the first fix was wrong. We assumed the application’s own “deleted” flag was the cause and had to follow the evidence to how the deletion was actually stored.
The same test repair turned up fifty-six failures. Comparing the failing test names with a checkout from before the session showed every one of them predated it. Most were tests checking behaviour the product had deliberately moved past, and one was a live bug.
What we changed
Code generation now counts deleted boards as well as live ones, so a retired board’s code is never handed out again. The interface that creates a site also now names the field and the rule that failed, instead of the bare message.
Afterwards the suite passed 296 of 296, against 226 before. The two changes are small. The value was in noticing that a bug this visible had been sitting behind a wall of unrelated red tests.
What it did not fix
The clearer error message was wired into creating a site only. Other routes that can fail a rule still report the bare message until someone does the same for them.
Nothing here brings a deleted board’s code back for reuse. That was not asked for, and reusing a code that invoices and photographs still point to would create a different problem.
The pattern, for anyone who retires records rather than erasing them
Whenever a system keeps deleted rows, ask which of its uniqueness rules still count them. A rule that does, combined with a generator that does not, is a fault waiting for the first deletion.
And whenever a screen says only “something went wrong”, ask whether the system knows more than it says. Here the database knew the field and the rule. The person at the screen was told neither.
Where this ends up
Adding a board is the first thing anybody does in AdBoard, the system that runs for Gold Sign Media, an outdoor media operator. It now works after a deletion, and when a rule is broken the screen says which.