The Fix Half-Worked. Back It Out, Don't Ship It Looking Done.

The filter fix looked correct for about 90 seconds. Then I noticed I had changed the dropdown builder, not the display loop that was actually suppressing the control.

This was in the visitor facing Tournament Brackets module. We had just brought back the competition filter and the find a team control, added Location Search, made the view tabs and search tools visible by default, and removed the old Display Type toggle. The filter row itself had three inputs: teams, competition, and location. The intended behavior was simple: build the available dropdowns once, then let the display loop decide which controls belonged in the active view.

I was trying to correct a missing filter in that final display step. The first patch appeared to do it. The control showed up, the page rendered, and the surrounding filter row still had the intended compact shape. It would have been easy to call that done and move to the next piece of feedback.

It was not done.

The wrong layer had changed

The diagnostic path was short once I stopped looking at the rendered row and followed the data backward.

First, I confirmed that the missing filter existed in the source list. It did. Next, I checked the branch that decides whether a built control is shown in the active view. That condition was still excluding the control under the state I was trying to fix. Finally, I traced the first patch. It had changed the code that assembles the dropdown definitions upstream.

That explained the misleading result. The builder change made the control available in one path, but the display loop still owned the decision I needed to alter. I had not repaired the selection rule. I had changed what was being handed to the rule.

That distinction matters in UI work. A builder can make a screenshot look healthy without making the behavior healthy. A partially correct configuration can populate the dropdown, preserve the pill styling, and survive a quick local click through. It can still leave the visibility logic wrong for another view or state.

I considered three ways to proceed

One option was to keep the builder change and add the display change on top. That lost because it would turn a narrow bug into two coupled edits. The next person reading the code would have to work out whether both were required, or whether one was residue from a failed diagnosis.

Another option was to keep the partial patch because it improved the immediate view. That lost for the same reason. A change that looks like the completed fix but only works because it altered an upstream component is worse than an obvious gap. It creates false confidence in review and makes the next regression harder to isolate.

The third option was to back out the builder change, return the branch to the last known behavior, and continue from the display loop. That was the right choice. It preserved the component sequence:

filter definitions
  -> dropdown builder
  -> display loop
  -> visitor filter row

The repair belonged in the third step. The first patch had landed in the second.

A clean revert is part of the diagnosis

We already had a live test setup for the broader bracket changes, so the pressure was not theoretical. The work had to match the requested direction, not merely render cleanly on my screen. I reverted the partial edit instead of leaving it behind as a head start.

That did not erase progress. It made the remaining problem honest. The filter inputs were still defined. The module still had the new competition, find a team, and location search capabilities. The unresolved question was now explicit: under which states should the display loop surface each one?

Leaving the partial change would have made the next pass harder. It would be tempting to read the builder edit as part of the finished design, then preserve it while adding the real visibility correction. Later, that becomes a condition nobody can justify.

A revert is not an admission that the debugging time was wasted. It is the point where the evidence gets strong enough to stop pretending the first theory was right. If the fix is in the display loop, leave the dropdown builder alone. Anything else can look finished while it teaches the codebase the wrong story.