When a GraphQL subscription is unsubscribed, what must the server actually cancel?

## Why this is more than one line of the algorithm The execution model defines an unsubscribe step whose whole content is: cancel the response stream. That looks trivial until you remember what the response stream is. It is not a source of anything — it is a *mapping* over the source event stream, producing one execution result per event. Cancelling the mapping stops results reaching the subscriber. It does not, by itself, stop events being produced. So the real question is what a correct implementation has to tear down, and interviewers who ask it are usually testing whether you have ever owned a long-lived stream in production rather than only read the algorithm. ## The chain of things that must die Work backwards from the subscriber. **The response stream.** Delivery stops. Straightforward, and the only part the algorithm names. **The source event stream.** This is the object the event-stream resolver returned at subscribe time. Cancelling the response stream must propagate here, because nothing else references it. **Whatever the event-stream resolver registered.** This is the part servers get wrong, because it is invisible to the execution engine. Opening a subscription on a translation-memory graph may have registered a filtered consumer on an event backbone, opened a change feed against a store, started a poll loop, or added an entry to an in-process registry of interested parties keyed by `projectId`. None of that is described by the schema, and none of it is released unless the source stream's cancellation is wired to release it. **In-flight per-event execution.** An event may have arrived a moment before the cancellation and be halfway through its selection set, holding request-scoped state and outstanding downstream calls. A server can legitimately let it finish and discard the result, or cancel it; what it cannot do is leave it holding resources indefinitely. **Per-subscription bookkeeping.** Rate limiters, per-subscription counters and metric registrations keyed by subscription identifier all outlive the stream if nothing removes them, and a metrics registry with unbounded cardinality is its own outage. ## What the leak looks like This is the diagnostic half of the question, and it is what makes it worth asking. Nothing errors. No subscriber complains, because the subscribers who would complain are the ones who left. Concurrent subscription count looks stable and correct. What grows is heap, upstream consumer registrations, and file or socket handles — and it grows in proportion to **churn** rather than concurrency. That signature is the tell: a page that reconnects on every navigation can produce thousands of subscribe-unsubscribe cycles an hour while never exceeding a handful of concurrent subscriptions, so a server that leaks one consumer per subscription looks idle by every count that anyone is watching. The secondary symptom is slower and stranger: orphaned consumers keep receiving events, so upstream fan-out grows, and per-event work rises against a fixed 340 ms p99 budget even though the number of real subscribers has not changed. Latency degrades on a system that appears to be under constant load. ## The teardown nobody writes a test for Worth naming explicitly, because it is where the bug usually is: the resource a subscription holds is not acquired by anything the schema describes. The schema says the root field returns a payload type. It says nothing about a consumer registration, and the execution engine cannot release something it was never told about. That is why the discipline has to be local to the event-stream resolver — the code that acquired the registration is the only code that knows it exists, so it is the only code that can attach the release to the stream it returns. ## What ends a subscription, and what it all funnels into Several things can end a subscription: the subscriber explicitly unsubscribing, the transport connection dropping, the server deciding to stop the stream, or the source event stream completing on its own. The useful design principle is that all of these should funnel into the **same** cancellation path. A server with one teardown routine for explicit unsubscribes and another for dropped connections will inevitably have the leak in the second one, because that path is harder to exercise in a test. The practical form of the answer is: make the source event stream's cancellation own every resource acquired when it was created — registered in the same place, released in the same place — rather than scattering acquisition across the event-stream resolver and release across the transport layer. Then test it by churning: open and close a few thousand subscriptions and assert that upstream registrations return to their baseline, which is the only check that catches this class of bug before production does.