The photo upload rule we deleted was doing a second job

A customer’s report was simple: adding a photo to an album kept failing with a generic error and no useful detail. We went looking for why.

The rule we took for a leftover

In the upload code we found a filename rule that only allowed letters, numbers, dots, underscores, and hyphens, and rejected anything else outright. Real photo filenames are full of the characters it refused: spaces, parentheses, apostrophes. A file the file browser had just listed as a normal image could still get turned away with “unsupported file type” for no reason a customer could see.

We read that rule as an overcautious leftover nobody still needed, and removed it. We committed the change believing we had closed a false rejection and nothing more.

Trying to break our own fix

Before calling it done, we built a small harness. It runs a batch of filenames, some ordinary and some deliberately adversarial, through the same code path and checks what comes out the other end.

The ordinary names all passed, as expected. Some of the adversarial ones passed too. Removing the whole-name whitelist had not only stopped rejecting spaces and parentheses. It had also stopped rejecting a kind of file that should never be treated as a photo, something the old rule had been catching as a side effect the entire time. The check had been doing two jobs, and we had only understood one of them.

A narrower rule

Reverting the whitelist was off the table, since real filenames still needed to work. So we wrote a narrower rule aimed directly at the danger the old one had been blocking by accident, while still accepting normal photo names. Run back through the harness, it let every realistic filename through and stopped every adversarial one.

Testing that second fix properly turned up something unrelated. Rotating a photo whose name had a space in it was already broken in production, with no visible error. One piece of code read a filename back out of a web-escaped link and handed it straight to a file lookup that expected the real name. It only surfaced because retesting meant exercising the code with a realistic filename instead of trusting that the earlier change had worked.

What went out

Both fixes shipped together in the next release: the corrected filename rule and the rotation fix, bundled with the original change. The gap between “removed the old rule” and “closed it properly” never reached a live server on its own. The whole sequence, first fix to corrected fix, took about half an hour on a Sunday night.

None of it was the failure the customer had actually hit. That was something else, found later the same night and fixed in the same release.

A rule we could only explain one reason for probably had a second reason we hadn’t found yet. The way to find it was to throw ordinary and deliberately hostile filenames at our own fix before we let ourselves call it finished.

dxdev LESSON · paste into your AI coding agent
LESSON: A Validation Rule You Call Overcautious May Be Doing a Second Job
SOURCE: dxdev.com/blog/the-check-i-called-a-nuisance-was-also-a-guard
WHAT HAPPENED: A customer's photo upload kept failing. One suspect was a filename rule that only allowed a narrow set of characters, rejecting perfectly normal filenames with spaces, parentheses, or apostrophes. Reading it as pure overcaution, the fix removed the whole-name check. Before it went anywhere, testing against a batch of deliberately adversarial filenames (not just realistic ones) found that the same removal had also reopened a way to disguise a dangerous file as an ordinary photo, something the old rule had been blocking as a side effect the whole time. The real fix aimed a narrower rule directly at that danger while still accepting normal names, and both changes shipped together in the same release the next day, so the gap was never live on its own. Retesting the fix properly also turned up an unrelated bug: rotating a photo whose name had a space in it was silently broken, found only because the retest exercised the code with a realistic filename instead of trusting the change had worked.
THE RULE: Before removing or loosening any input-validation rule because it rejects legitimate values, ask what else, besides the false rejections, it might also be blocking, and test the replacement against deliberately hostile input, not just the realistic input that motivated the change in the first place.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any input-validation rule about to be loosened or removed because it rejects legitimate values, where nobody has checked what else it was blocking.
  2. Any place a filename, path, or user-supplied string is trusted as "already checked" further downstream from where the original check ran.
  3. Any recent fix to a validation rule that was verified only against realistic input, with no adversarial or edge-case input tried against it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.