The size guard I shipped didn't run

A customer typed “Youth Extra Large” 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

I 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 I moved on.

It did nothing. The guard was correct code sitting 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.

Finding out the hard way

I 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. I was most of the way through closing the ticket when a pointed question stopped me: hadn’t these popups already been migrated, and was I sure the page I had just patched was even still in use? Tracing the actual click path, not the file I remembered editing, showed the guard 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 I knew where to look. Verifying it took longer: I 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.

The habit this forces now

“I fixed the validation” and “I fixed the validation in the code that actually runs when someone clicks save” are different claims, and only one of them is worth anything to the person hitting the bug. A length guard sitting 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.

The rule I took out of this: before calling a validation fix done, trace the live entry point by hand. Not the function with the right name, not the file that used to own this feature, the one thing the current UI actually invokes when a real person clicks the real button. If you can’t point to that call chain, you haven’t verified the fix, you’ve verified 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/2026-08-14_guard-shipped-into-dead-code
WHAT HAPPENED: A registration form let people type a free-text shirt or shorts 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.