A web framework auto-configured a default nobody wired — how do you find where it came from and override it?

## Why this is a senior question The skill being tested is not "can you change a default" — it is whether you **establish provenance before editing**. A default you did not wire came from a decision the framework made, and that decision has a name, a condition, and an owner. Engineers who skip this step end up bisecting the dependency list or copying a fix from an unrelated write-up, and the change works for a reason they cannot state. ## Step one: make the wiring visible The mechanisms available in this family of frameworks are consistent even where the names differ: - a **startup report** of conditional units: which matched, which did not, and the condition that decided it; - a **verbose boot log** enabled by a setting, printing registrations as they happen; - a **runtime query of the effective registration** for a role — ask the object graph what actually implements it, and where that instance came from; - **effective settings dumps**, showing the value in force and, in better implementations, which source supplied it. Run these before touching code. The goal is one sentence: *unit X registered component Y for role Z because condition C held.* ## Step two: pick the narrowest seam Seams, roughly from narrowest to widest: | Seam | What it changes | When it is right | |---|---|---| | Set the value the unit reads | One knob of one default | The default is nearly right; a documented setting exists | | Configuration block at install time | The unit's own options before it registers | You install the unit explicitly and want a different shape | | Register your own component for the role | Which implementation fills one role | You need different behaviour, not a different value | | Order or precedence declaration | Which of several registrations wins | Two units legitimately both apply | | Exclude or disable the unit | Everything that unit contributes | The unit is wholly wrong for this service | The rule of thumb: **change the decision, not the mechanism**. Prefer a seam the unit's author designed for, because those survive upgrades; the wider the hammer, the more of the unit's other registrations you silently drop. Disabling wholesale is not forbidden — sometimes a unit's assumptions genuinely do not apply — but do it knowing what else leaves with it. One trap deserves its own line. Registering your own component works only if the unit backs off on an existing registration, and only if yours is visible when that condition is evaluated. Where a unit registers unconditionally, your registration may lose, or worse, both may be present and the winner decided by order. That is a case for an explicit exclusion or precedence declaration rather than hope. ## Step three: pin the outcome A fix that is invisible to the build will be undone by the next upgrade, because the thing you changed was a **decision made from the dependency graph and settings**, both of which move without anybody editing your service. 1. Write a **startup test** that boots the application and asserts the effective implementation for the role — not that the setting has a value, but that the right component won. 2. Where the behaviour is user-visible, add a **thin end-to-end check** on the observable shape (a response content type, a body format, a header the feature adds). 3. Leave a **comment or short note at the override site** naming the unit you overrode and why. The next reader's question will be the same one you just answered. ## What this looks like when it goes wrong - **Fix by deletion.** Dependencies are removed one at a time until the symptom disappears, and the service ships without a feature it needed for an unrelated reason. - **Fix at the wrong altitude.** The whole conditional-wiring mechanism is switched off to get rid of one default, and the service takes on the full wiring burden it was never designed for. - **Fix by shadowing.** A second registration is added without checking precedence, so both exist and behaviour depends on order — which then differs between a local run and production. - **Fix without a test.** The override is a settings line nobody knows the reason for, so the next person cleans it up. ## The general principle Conditional defaults are a loan of decision-making to the framework. When you take a decision back, take it back **explicitly, at the narrowest point, and with an assertion that keeps it** — that is what makes a service with heavy auto-configuration operable rather than mysterious.