A webhook receiver dedupes with a dict subclass whose __missing__ registers the event id; after a membership guard was added, handlers fire twice. How do you diagnose it?

## Reading the failure The symptom is a duplicated side effect: a webhook redelivery runs the handler again. The proximate cause is a change in *how the mapping was accessed*, not in what the mapping stores. That shape — behaviour changed by a read that looks equivalent — is the fingerprint of logic living inside a miss hook. `__missing__` runs on exactly one path: `dict.__getitem__`, which is the `d[key]` syntax. The containment operator, `dict.get()`, `dict.pop()`, `dict.setdefault()`, iteration and the view methods all consult the hash table directly. So the original code, whatever it looked like, was reaching registration through subscription — probably something like `if seen[event_id]: return` — and the refactor to a membership guard removed the only call site that triggered it. ## Confirming it fast Do not reason about it in review; make the interpreter answer. Three lines: ```python seen = Seen() before = len(seen) "evt-1" in seen assert len(seen) == before # passes: membership registered nothing seen["evt-1"] assert len(seen) == before + 1 # the hook only runs on subscription ``` If the mapping is behind an abstraction, instrument the hook itself — a counter incremented in `__missing__`, printed at the end of a request — and observe that it stays at zero under the new code path. In a live service, the same evidence comes from a metric on hook invocations plotted against redeliveries: the two used to move together and now do not. Check the deployment story too. A duplicated side effect at a webhook receiver has several classic causes — retries with an at-least-once sender, a load balancer replaying a request, two instances consuming the same delivery, dedupe state living in a per-process dictionary that a second worker does not share. Confirm the mechanism before you commit to the mapping explanation: if the hook never fires under *any* code path, it is the mapping; if it fires once per process but you have four processes, the dictionary was never the right place for the state. ## The fix, and why the obvious one is wrong The obvious fix is to change the guard back to subscription. Do not. It restores the behaviour by re-establishing an invisible coupling: correctness now depends on nobody ever writing `in`, `.get()`, or a debugger watch expression against that mapping. The next person to make the same reasonable edit reintroduces the same outage. The durable fix is to stop hiding an effect behind a read. Give the container an explicit operation whose name says what it does: ```python class Seen: def __init__(self): self._ids = {} def claim(self, event_id): """Return True if this id had not been seen before.""" if event_id in self._ids: return False self._ids[event_id] = True return True ``` No inheritance from `dict`, no hook, no mapping contract to honour — and the call site reads `if seen.claim(event_id):`, which cannot be refactored into something that silently skips the effect. Note the second benefit: because this is a plain class, the check-and-store pair is now a single method you can make atomic under a lock or back with a shared store, which a bare mapping never let you express. If you must keep a mapping, keep the hook **pure**: let `__missing__` compute and return a default, and store nothing. A pure hook cannot be the difference between one side effect and two. ## Preventing the class of bug Write the regression test at the level the bug lives — a redelivery of an already-processed id must not invoke the handler — rather than asserting on the mapping's internals; the internals are what you want free to change. When the receiver already has a large regression pack (a 340-case corpus of recorded deliveries, say), the useful addition is a small number of *duplicate* cases interleaved into it, not 340 more; the pack's job is to exercise the guard on every handler, and duplicates only need to prove the guard runs at all. Then sweep. Any class that defines `__missing__` with a body doing more than computing a value is a candidate for the same failure. So is any `dict` subclass overriding `__setitem__`, for the mirror-image reason: `update()`, the constructor and `setdefault()` bypass it. Both are cases of the same rule — in CPython, the inherited built-in methods and the dunder hooks agree with each other far less than the code reads as though they do. ## The judgement being tested A senior answer diagnoses in minutes and then argues about design: state changes belong in operations named after the change, containers should not surprise readers on read paths, and a guard whose correctness depends on which accessor a colleague picks is not a guard. Getting to "membership does not call the hook" is table stakes; the interview turns on what you do next.