The filter fix looked correct for about 90 seconds. Then we saw that we had changed the dropdown builder, and the display loop that was actually suppressing the control was untouched.

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

The missing filter was a problem in that last step. The first patch appeared to fix it. The control showed up, the page rendered, and the filter row kept its compact shape. It would have been easy to call that done and move on to the next piece of feedback.

It was not done.

Following the data backward

Once we stopped looking at the rendered row and followed the data backward, the diagnosis was short.

First we confirmed the missing filter existed in the source list. It did. Next we checked the branch that decides whether a built control is shown in the active view. That condition still excluded the control in the state we were trying to fix. Then we 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 we needed to alter. We had not repaired the selection rule. We had changed what was handed to it.

A builder change can make a screenshot look healthy while the behavior stays wrong. Our partial change populated the dropdown, kept the pill styling, and survived a quick click through locally. The visibility logic was still wrong for other views and states.

What we did with the partial patch

We had a live test setup for the broader module changes, so the first patch had already looked good on a real page. The work had to match the requested direction, and rendering cleanly on our screen was not enough.

We did not build on top of the builder change. Keeping it and adding a display change would have turned a narrow bug into two coupled edits, and the next reader would have to work out whether both were required or whether one was residue from a failed diagnosis. We did not keep it for the sake of the improved view either. A change that looks like the finished fix but only works because it altered an upstream component is worse than an obvious gap, because it gives review false confidence and makes the next regression harder to isolate.

So we backed out the builder change and returned the branch to the last known behavior. The component sequence stayed as it was:

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

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

After the revert

The revert did not erase progress. The filter inputs were still defined, and the module still had the new competition, find a participant group, and location search capabilities. What remained was one explicit question: under which states should the display loop surface each control?

Leaving the partial change in place would have made the next pass harder. It would have been tempting to read the builder edit as part of the finished design and keep it while adding the visibility correction. Later it would be a condition nobody could justify.

The revert marked the point where the evidence was strong enough to stop treating the first theory as right. The fix lives in the display loop, so the dropdown builder stays as it was.

A fix that renders correctly can still sit in the wrong layer of the system. When a change looks done, check where in the code it landed and whether that layer owns the behavior.