The wrench dialog said the competition and find-a-team filters should be showing on the rebuilt module. On the live test site, they weren’t. Nothing in the rendering code was broken. Three layers disagreed about one default value.
We were reworking the module after feedback: restore those missing filters, make every view tab and search tool available by default, add a Location Search option, fix a wrench checkbox that would not save when unchecked, remove the Display Type toggle, and rename the module. The missing filters were the exact regression the rebuild was supposed to close, and it was still open on the site we were about to hand back for review.
We started with the filters. We would find the code that renders them and work out why they had stopped.
The renderer was fine
The rendering code for both filters was fine. The regression was one level up, in what each part of the system believed the default should be.
A shared options library set one default.
The wrench dialog’s apply logic wrote a different one when it saved a change.
The display template that showed the current setting back to the admin assumed a third.
Three places, three answers, and none of them was wrong on its own. Change any one of the three in isolation and the filters would look fixed on whichever screen you were staring at, while staying broken everywhere the other two mattered.
The fix that would have looked right
The fast fix was sitting right there: hardcode the filters back on in the renderer and close the ticket. It would have worked, on that one screen. It also would have left the disagreement in place for whoever next touched the wrench dialog or the options schema, with no reason to expect three sources of truth for one setting.
The fix we made aligned the default across the options library, the wrench’s apply logic, and the display template. Then we checked that the admin screen, the wrench dialog, and the live module all agreed at once. The Location Search addition, the checkbox save bug, the Display Type removal, and the module rename went into the same pass. All of it was verified end to end on the test site before the branch was committed.
One screen only tells you about one layer
Reading the renderer, or testing one dropdown, would have confirmed the fix looked right without ever showing that two other layers still disagreed. The only way to know the setting was fixed was to trace it through every place that defined or read it and confirm they told the same story.
The filters were never broken. The system couldn’t agree with itself about what “on” meant, and nothing forced it to check until we looked in all three places at once. When a setting looks broken on one screen, find where it is defined, saved and displayed, and confirm all of those agree before you close the ticket.
AI Skills
Use this lesson with the AI assistant you already use
Missing filters looked like one broken piece of rendering code. The fault was a single default value with three separate owners, an options library, a dialog's apply logic, and its display template, each holding its own answer for the same setting.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A setting that lives in more than one layer can be "fixed" in one place and still wrong everywhere else
SOURCE: dxdev.com/blog/the-missing-filters-were-a-drifted-default
WHAT HAPPENED: Two filters that should have been showing on a rebuilt module were not showing on the live test site. The rendering code for both filters was fine, which made it tempting to patch the renderer directly and call the regression closed. The cause sat one level up: a shared default value had three separate owners in the codebase, a shared options library that set one default, a dialog's apply logic that wrote a different one when it saved, and the display template that assumed a third, and none of the three was individually wrong. Patching only the renderer would have made the one screen being tested look correct while leaving the other two owners still disagreeing, a regression waiting for the next person who touched either of them. The fix aligned the default across all three owners, then verified the setting agreed everywhere it was read, not just on the page that was open.
THE RULE: When a bug is a single symptom of a setting that is defined or read in more than one place, a fix that only touches the place you found first can look correct while leaving the actual disagreement in place. Before closing a "missing" or "wrong default" bug, find every layer that owns or reads that value and confirm they agree, not just the one you're staring at.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any fix for a "missing" or "default is wrong" bug that changes only the layer where the symptom appeared (the renderer, the UI), without checking whether the same setting has another source of truth (a config default, an apply/save path, a schema) that could still disagree.
2. Any shared default or setting that is defined, read, or written in more than one file/module without a single canonical source the others defer to.
3. Any regression fix verified only on the one screen where the bug was noticed, without confirming the same setting reads correctly everywhere else it's used.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
