The flag flip was a one-line change. auto_mode had been off in production for months. This was deliberate, while the article pipeline was being validated. On 2026-09-17 it went back on. Three tests in tests/dvlaw/test_post.py broke before the day was out.
assert 0 == 2
Not flaky. Consistent. Every run.
The obvious diagnosis: something in the 2026-09-17 commit had broken post_today. That’s what a same-day test failure implies — you shipped, tests broke, the code is at fault. Wrong. The commit hadn’t touched post_today, or the test files. In production the function was behaving identically. The only disagreement came from the test suite, which meant the tests had been wrong for some time before that.
What post_today does
post_today reads the auto_mode flag before deciding whether to post candidates to Telegram. It doesn’t accept the flag as an argument. Instead, it opens its own SQLite connection to dvlaw.db and reads it directly.
That internal connection is the problem. The test fixtures for these three tests controlled a separate test database. post_today was opening a second connection to the operator’s live dvlaw.db. The fixture controlled one surface. The function was reading from another.
Improving on the earlier coverage in “the fixture isolated the test — the connection bypassed it”: that article established how the bypass worked. What it left open is why the tests had been green for months despite the bypass being present from the start.
The masking mechanism
When auto_mode was off in production, both paths returned the same value. It had been off since the pipeline was first set up. The test fixture said off. The operator’s live dvlaw.db, which post_today was reading, also said off. The assertion passed. The tests were green.
The coincidence held for as long as auto_mode stayed off. The tests weren’t hermetic; they were accidentally consistent with production state. Every test run, both sources agreed, and that agreement looked like a passing test.
The masking isn’t a coincidence in the usual sense. It’s structural: production flags that default to off during a validation period align exactly with what the test fixture returns for an uninitialised flag. The cautious default that keeps production quiet while the pipeline is being built creates the very condition that hides the leak.
There is no observable symptom when two data sources agree by accident. The test output is indistinguishable from a correctly hermetic test. No flakiness. No dirty state between runs. No unexpected writes. Clean green output, every run, for months.
The moment auto_mode went back on in production, the two paths diverged. The fixture still returned off. The live database returned on. post_today read the live database, as it always had, and the assertion caught the discrepancy.
assert 0 == 2 is not a regression. It’s the test noticing a divergence it had never been equipped to see. The function had been reading live state the entire time. Production’s flag being off was the alibi.
Why this class of masking doesn’t surface
The usual case for hermetic tests is built around visible side effects. A test that writes to a real database leaves dirty state; subsequent runs break. Read from a real database with changing data, and you get intermittent failures. Both shapes surface quickly because the failure is observable: dirty state is traceable, flakiness is noticeable.
The post_today case fits neither shape. The leak is a read from a source that returns stable data. The live dvlaw.db flag doesn’t change between runs — it reflects current production configuration, which changes only when an operator changes it. For as long as the operator doesn’t change it, the read from the live database returns the same value the fixture would return, and the test passes.
No tooling catches this during the quiet period. Static analysis can’t distinguish a connection to test data from a connection to live data without understanding path resolution at runtime. Test output is clean. The only signal is the moment external state changes and the two paths stop agreeing.
The fix
Making the three tests hermetic was a one-commit change, dated 2026-09-18. The fix ensured post_today reads auto_mode from the same connection the test fixture controls.
Once I asked the right question, the diagnosis was fast: which database is post_today opening, and does the test fixture control it? The answer to the second question was no. That was the whole problem.
Out of scope: auditing the rest of the article pipeline test suite for similar second-connection patterns. The three post_today tests are clean. The broader audit is a separate pass.
What to check for
The class of problem is predictable from one property: a function that opens its own I/O connections rather than receiving them as injected dependencies.
Dependency injection closes this gap by construction. If the test fixture creates the connection and passes it to the function, there’s no second connection to diverge from. The fixture is the only source. Agreement isn’t coincidental; it’s enforced.
When a function opens its own connections internally, the fixture has no visibility into them. Any agreement between the fixture’s database and the function’s database is coincidental and conditional on whatever production state happens to be at the time the test runs.
For any function with internal I/O: does it open connections or file handles the test fixture doesn’t control? If uncertain, find out. External state will answer the question eventually, on its own timing. The post_today failure surfaced when a configuration flag went back on after months of being off. It could have surfaced when someone ran the test suite on a machine with a different dvlaw.db. Or it might have stayed hidden until a different change diverged the paths in a less obvious way.
Silent agreement is the worst kind of test pass. The code can be wrong for months, the test runs can be clean, and nothing in the output tells you the two sources only agreed by accident.
