The Second Hotfix Was the Honest One

A contact form shipped a small set of new links late one morning. Clean release, no complaints, nothing on fire. Eight minutes after it reached the main branch, a second release went out to fix a default the first one had quietly broken.

What the first release did

The form had grown a handful of new entry points, each one landing a visitor on a slightly different pre-filled message depending on which link they’d clicked. To make the follow-up easier on the reading end, each new link also carried an identifier for the specific account it came from, so the form could pre-fill who was asking without making them type it.

That identifier was not a new field. It reused an existing optional parameter the form had carried for years, one that a couple of much older, unrelated cases also happened to set.

The rule that had never been tested against this

Buried in the form’s priority selector was a rule that decided which option came pre-checked in a dropdown: medium, unless the request carried that same optional parameter, in which case skip the pre-selection entirely and let the dropdown fall through to its first, lowest option. For as long as that rule had existed, the only requests that ever set the parameter were a couple of specific, older cases where leaving the field on its lowest setting was the deliberate outcome.

The new links set the same parameter for a completely different reason: not to say “leave this low,” but to say “here’s who’s asking.” The rule had no way to tell those two intentions apart, because it had only ever been asked about one of them. It didn’t misfire. It did exactly what it had always done, for a category of caller it had never previously seen.

What actually happened

Every one of the new links landed a visitor’s message on the lowest priority option by default, silently, with no error and no visible sign that anything was wrong. The form worked. It just under-flagged every message that came through those new links, and nothing about the page would have told anyone that.

The fix

Caught the same day, before the release cycle moved on to anything else. The rewrite replaced the general condition with the one specific case it had actually been written for, so the new links get their correct default and the original two cases keep theirs. One conditional, four lines, shipped as its own release about eight minutes after the first one landed.

What it says about testing a rule that’s never been wrong

A conditional that has passed every test it’s ever been given is not the same as a conditional that’s correct. It’s a conditional that has only ever met one shape of caller. The moment something new arrives that happens to satisfy the same general condition for a different reason entirely, the old rule doesn’t get confused, it just applies itself faithfully to a situation it was never actually written for. The fix wasn’t to make the rule smarter. It was to make it stop answering a question it was never actually being asked.

dxdev LESSON · paste into your AI coding agent
LESSON: A Default That Falls Through Silently Is a Bug Waiting on a New Caller
SOURCE: dxdev.com/blog/2026-07-31_the-second-hotfix-was-the-honest-one
WHAT HAPPENED: A shared form had an old rule for pre-selecting a priority value: skip the default selection whenever the request carried a certain optional context. For years, only a couple of code paths passed that context, and both had a reason to leave the field on its lowest option, so the rule was invisible. A release shipped a set of brand-new links that also happened to pass that same context, for a completely different reason: to identify who was asking. The old rule fired anyway, and every one of those new links landed on the lowest priority option by default. It was caught the same day, in the same release cycle, and fixed with a second, narrower release about eight minutes after the first reached the main branch: the exemption was rewritten to name the one case it was actually meant for, instead of the general condition that happened to be true for it.
THE RULE: an old conditional that has only ever seen one shape of input is not proven correct, it is untested against every other shape. Adding a new caller that satisfies the same condition for an unrelated reason does not trigger the bug randomly, it triggers it every time, because the logic never distinguished "this specific case" from "this general condition."
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any conditional written against a general property (a flag, a non-empty field, a shared parameter) when the actual intent was one specific value or one specific caller.
  2. Any new feature that reuses an existing optional field or parameter for a new purpose, without checking every existing branch that already reads that field.
  3. Any default-selection or fallback logic where "no branch matched" silently becomes the lowest, weakest, or most restrictive option, without that being an explicit, named decision.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.