A One-Line Fix Almost Broke a Test From Five Weeks Ago

Here's a bug class I didn't know to be scared of until this week: two completely unrelated pieces of code agreeing, by accident, on the same identifier.

Every session an agent runs here is supposed to end by writing its own log — a record of what it did. Once in a while one doesn't, and the merged work it left behind sits "orphaned," with no log to explain it. There's a scheduled sweep called frictions-to-fixes — it reads recent work for recurring snags and files tickets to fix them — and this week it noticed something small: the map that's supposed to record which orphan reports a human already decided weren't worth chasing (closed wontfix) had been sitting empty since it was added, even though two real ones already qualified — #736, an orphan from a session that built a GitHub-comment guard, and #1063, one from a session that added a history page. The fix looks like the most boring diff you'll see all month: two entries added to a Map. I'd have shipped that in under a minute and moved on.

What stopped me is what the agent assigned to fix it checked before shipping: whether either of those session IDs showed up anywhere else in the codebase, hardcoded. One did. session_019aeaoPHYWMJVekmUvTMhQ9 — now a real entry pointing at #736 — was also a literal fixture in an existing regression test for a completely different bug: issue #747, where the same orphan-finding code had a separate flaw that was wrongly suppressing a genuine orphaned session — this exact one, #736, hidden for a week. The #747 test calls the orphan-finder with no fourth argument, relying on a default — which, as of this same PR, quietly stopped being an empty map. Ship the one-line fix without checking, and a test written five weeks ago for an unrelated bug starts silently exercising a different code path than the one it was written to test, because the ID it happened to reuse as fixture data just became "real" data somewhere else.

The actual fix threads the needle: the #747 test now passes an explicit empty map as that fourth argument instead of relying on the default, with a comment explaining exactly why, and a second, new test asserts the real default map resolves both entries correctly. Trace through what happens without that isolation: the #747 test's own assertion checks the whole returned object matches exactly, field for field, and the moment session_019aeaoPHYWMJVekmUvTMhQ9 became a real entry in the default map, that same call would start returning one extra field — resolvedBy: '#736' — that the five-week-old test never expected and an exact-match check doesn't forgive. So this wasn't a silent bug waiting to be found later, it was a same-PR test failure that got caught and isolated before it ever shipped, for a test about a completely different bug (a suppression flaw in the orphan-finder, not the closed-report annotation) that had no business caring about this change at all. That's the part I can't shake: nothing about "populate an empty lookup map with two entries" reads as risky, and the only reason it stayed safe is that someone checked whether either of those two IDs showed up anywhere else in the codebase as a hardcoded string. I write plenty of fixtures with real-looking IDs in them. I have never once grepped the repo to check whether my fake ID was about to become someone else's real one.