The shirt-size overflow that took down a whole registration import

A customer typed a long size description into a shirt-size field, hit submit, and lost the entire registration, not just the row with the bad value. The field was free text, the database column had a length limit, and the overflow threw an error that took the whole import down with it.

The first fix looked complete

We built canonical size codes so the field would be a dropdown instead of free text, and added a length guard to the save path so anything too long would fail cleanly instead of crashing. It compiled, it deployed, and we moved on.

It did nothing. The guard was correct code in the wrong place: an older dialog handler that used to own the save action, before the live “edit this field” flow was rebuilt to call a different function entirely. The path a real edit actually runs through had no length check at all, the same as before the fix shipped.

Testing the wrong thing

We had already tested the guard against the live production endpoint, watched it come back clean instead of crashing, and called that definitive proof the fix was live. We were most of the way through closing the ticket when a pointed question stopped us: hadn’t these popups already been migrated, and were we sure the page we had just patched was still in use?

So we traced the actual click path instead of the file we remembered editing. The guard was sitting in dead code. Nothing in the current UI called it anymore. Whatever used to route through it had been replaced, and nobody had gone back to delete the old handler or update the comment claiming it was still load-bearing.

Moving the guard to the real save path took a few minutes once we knew where to look. Verifying it took longer. We ran the same over-length value through the actual edit dialog and confirmed it came back as a clean validation error instead of a crash, then ran a normal, valid value through the same path to confirm nothing else broke. Both hotfixes shipped to production.

What the guard proved

Saying we fixed the validation and saying we fixed the validation in the code that runs when someone clicks save are different claims, and only the second one helps the person hitting the bug. A length guard in a function nothing calls is indistinguishable from no guard at all, right up until someone reads the diff and assumes the problem is solved.

Our earlier test had passed, and that was the trap. It showed the endpoint behaved, and it never showed that the endpoint was reached from the button a customer presses. Before calling a validation fix done, trace the live entry point by hand: the one thing the current UI invokes when a real person clicks the real button. If nobody can point to that call chain, the fix is unverified, because all we have shown is that some code somewhere now has a guard in it.

dxdev LESSON · paste into your AI coding agent
LESSON: A Fix Isn't Shipped Until You Confirm the Save Path Actually Calls It
SOURCE: dxdev.com/blog/guard-shipped-into-dead-code
WHAT HAPPENED: A registration form let people type a free-text size. A long value overflowed the database column and crashed the entire import, taking the rest of that person's registration down with it. The first fix added canonical size codes and a length guard, and it deployed clean. It also did nothing, because the guard was written into an old form-save handler that the live "edit this field" dialog no longer called. The actual save path had no length check at all. The second fix moved the guard to the real path and verified it live, on both sides of the check, before calling it done.
THE RULE: A validation fix is not verified by "the code compiled" or "the deploy succeeded." It is verified by proving the exact user action that used to break now goes through the exact code you changed. Before marking a data-validation fix done, find the live entry point (the actual button, dialog, or API call a user triggers) and confirm your changed code sits directly in that path, not in a sibling function, an older version of the same dialog, or a handler kept around from a previous UI.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any recently-added validation, guard, or length check whose call site was not traced back to a live, user-triggered entry point.
  2. Any form or dialog with more than one save/submit handler in the codebase, where it's unclear which one the current UI actually invokes.
  3. Any fix accompanied by a deploy log or "shipped" note but no before/after evidence of the actual failing action being re-run against the new code.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.