28 August 2026code4 min read

the bug that looked like nothing

I shipped a privacy feature that matched on a prefix the site does not use. It failed open, so it failed silently — and the fix turned on a regex anchor that can never fire.

IGFocus has a switch called Ghost Mode. Turning it on is supposed to mean you can read a DM without the other person being told, and watch a story without joining the viewer list. It works by dropping the requests that carry those signals before they leave the browser.

The first release of it did nothing at all. Not intermittently, not on some accounts — nothing, for everybody, for the whole time it was live. And the reason I did not notice is the same reason I would build it that way again.

Failing open

The two ways this feature can be wrong are not the same size. If a read receipt slips through, someone learns you saw their message a few seconds earlier than you would have liked. If the pattern is greedy enough to swallow the request that *sends* a message, the user's inbox is broken and they have no idea why, because from the outside a message that was never sent and a message that failed to send look identical.

So the whole system is written to fail open. Anything shaped like a send is never dropped, whatever is batched alongside it. When the interceptor is unsure, the request goes through.

That is the right call, and it is also what hid the bug. A pattern that matches nothing behaves exactly like a pattern that has correctly decided to let everything through. There is no error, no log line, no failed request — the feature is on, the switch is green, and every single receipt is being delivered.

Matching a name that was never sent

The patterns were written against operation names I had guessed from the shape of the API rather than read off the wire. I matched anything beginning Direct — DirectMarkThreadRead, that family. Instagram's web client does not use those names. Nothing matched, and because nothing matched, nothing was dropped.

The fix was to stop guessing and match on shape instead of on a prefix I hoped was there: the operation names that actually appear, matched by the parts of them that are stable rather than by a leading word that is not.

the second mistake, and why it is worse than the firstjs

// Does not fire. Ever.
/\bmarkThreadRead\b/.test("useDirectMarkThreadReadMutation")
// → false

// \b is a boundary between a word character and a non-word
// character. These names arrive glued into camel case, so every
// position inside them sits between two word characters — there
// is no boundary anywhere for the anchor to match.

I had reached for \b on reflex, the way you do when you want to avoid matching a substring inside a longer word. It is the correct instinct for prose and exactly wrong here. markThreadRead inside useDirectMarkThreadReadMutation is bounded on both sides by letters. There is no boundary. The anchor cannot fire, and a regex that can never match is, again, indistinguishable from a regex that has decided not to.

Not one pattern in the file uses \b now. There is a comment above them saying why, because this is the kind of thing that gets helpfully added back by someone tidying up.

Testing the thing, not a drawing of the thing

The lesson I actually took from this is not about regex. It is that both bugs were the same bug: I had tested my belief about the system instead of the system.

The test suite that exists now does not mock the interceptor. It compiles it exactly the way production does, minifier included, drops it into a stand-in page, and pushes a receipt down every transport it is supposed to cover. Then it takes the blob the interceptor hands to the SharedWorker and executes *that* in a stand-in worker, because the second copy of a DM read receipt comes from the worker backing the inbox, which has its own global scope and its own fetch and never saw any of the patches.

If a transport is not exercised end to end, assume it is not covered.
Assert the positive: something was dropped. "Nothing broke" is not a passing condition for a feature whose success state is silence.
Compile the real artefact. A minifier is allowed to be the thing that breaks you.

None of that is clever. It is just the difference between a test that would have caught this and the tests I had, which all passed while the feature did nothing whatsoever.

Failing open

So the whole system is written to fail open. Anything shaped like a send is never dropped, whatever is batched alongside it. When the interceptor is unsure, the request goes through.

Matching a name that was never sent

the second mistake, and why it is worse than the firstjs

// Does not fire. Ever.
/\bmarkThreadRead\b/.test("useDirectMarkThreadReadMutation")
// → false

// \b is a boundary between a word character and a non-word
// character. These names arrive glued into camel case, so every
// position inside them sits between two word characters — there
// is no boundary anywhere for the anchor to match.

Not one pattern in the file uses \b now. There is a comment above them saying why, because this is the kind of thing that gets helpfully added back by someone tidying up.

Testing the thing, not a drawing of the thing

The lesson I actually took from this is not about regex. It is that both bugs were the same bug: I had tested my belief about the system instead of the system.

If a transport is not exercised end to end, assume it is not covered.

Assert the positive: something was dropped. "Nothing broke" is not a passing condition for a feature whose success state is silence.

Compile the real artefact. A minifier is allowed to be the thing that breaks you.

None of that is clever. It is just the difference between a test that would have caught this and the tests I had, which all passed while the feature did nothing whatsoever.