---
title: "Why Every Message From the New Links Arrived Marked Lowest Priority"
canonical: https://dxdev.com/blog/the-second-hotfix-was-the-honest-one/
datePublished: 2026-08-01
---
Eight minutes after a contact form release reached the main branch, a second release went out to fix a default the first one had broken. The first one had looked clean: it shipped late one morning with no complaints and nothing on fire.

## Links that carried an account identifier

The form had grown a handful of new entry points. Each one landed 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.

## A selector rule with one kind of caller

Buried in the form's priority selector was a rule that decided which option came pre-checked in a dropdown. The default was medium, unless the request carried that same optional parameter. In that case the rule skipped the pre-selection entirely and let the dropdown fall through to its first, lowest option.

For as long as the rule had existed, the only requests that set the parameter were those couple of 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: to say "here's who's asking." The rule couldn't tell the two intentions apart, because it had only ever been asked about one of them. It did exactly what it had always done, for a caller it had never seen.

## What the visitors got

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

## The four-line fix

We caught it 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. The new links get their correct default, and the original two cases keep theirs. It was one conditional, four lines, shipped as its own release.

## A rule that had never failed

A conditional that has passed every test it has been given is not necessarily correct. It has only met one shape of caller. When something new arrives that satisfies the same general condition for a different reason, the old rule applies itself faithfully to a situation it was never written for. The fix made the rule stop answering a question nobody was asking it.

So when a new feature reuses an existing field or parameter, go find which older rules key off it, and check whether they still mean the same thing.