The request timeout needed to go up for a slow batch export. The agent opened the config, did not locate the existing timeout entry, and added a second one further down the file. The app booted, the test that read the new block passed, and the change looked done.

The old timeout was still sitting above the new one, and the parser had silently discarded it. Nothing warned anyone that the file defined the same key twice.

Lenient parsing makes duplicates look harmless

Many config formats tolerate a repeated top-level key by taking the last occurrence. That behavior is convenient for machine edits, but it turns a structural mistake into a silent overwrite. The value a team tuned weeks ago is still present in the file; it is simply ignored, and there is no parse error to point at in CI.

JSON and several YAML and INI parsers follow last-wins with no warning by default. The human reading the file sees two settings, assumes both apply, and has no way to tell which one the runtime actually picked without checking the parser itself.

Why the green check missed it

The test read the value the agent had just written, so it saw the new timeout and passed. It never compared against the original entry or asked whether the file contained the key once. A unit test on the resolved config does not expose duplication; it only confirms the last value survived.

Reviewers scanning the diff also see a new block with the right number, not a conflict. The problem is the absence of a diagnostic that says this key already exists above, and that diagnostic never runs because the file parses cleanly.

The failure is quiet and hard to reproduce locally

The wrong timeout usually surfaces under real load, when the batch export actually hits the slow path. Local runs exercise the new value because the last block happens to be near the top of recent memory, while production keeps resolving the same shadowed pair. There is no crash, no failed assertion, and no migration log entry to trace back to.

Over time the file accumulates a few repeated keys, each last-wins against the one above it, and nobody remembers which occurrence the runtime honors.

Flag repeats explicitly and print the resolved value at boot

The cheap fix is strict parsing: error on a repeated key instead of choosing one quietly, or at least emit a warning naming the duplicate and which occurrence won. During review, treat an added key as a search for the existing key first; editing the current block beats appending a new one.

A startup check that logs the fully resolved, effective value for each setting turns silent shadowing into an observable line. You cannot defend a config the runtime resolves invisibly. What does your parser do when the same key appears twice — keep the first, keep the last, or reject it?