In a GraphQL subscription, what value does the selection set execute against per event?

## The one sentence that explains most subscription bugs Each event is executed, not serialized. The server takes the source event, uses it as the **initial value** for a normal execution of the subscription operation's selection set, and yields the resulting `{ data, errors }` map. The algorithm for that execution is intentionally the same one a query uses, which is why the answer to "how is my subscription payload built?" is always "the same way a query's payload is built — from a root value, through resolvers". ```pseudocode function executeSubscriptionEvent(document, schema, variables, event): subscriptionType = schema.subscriptionRootType selectionSet = document.operation.selectionSet data = executeSelectionSet(selectionSet, subscriptionType, initialValue = event, variables) return { data: data, errors: collectedFieldErrors } ``` ## The root field is resolved twice, by two different things This is the detail interviews probe, and it is worth stating in exactly these terms. The subscription's root field has **two** jobs on a server: 1. At subscribe time it is resolved by the **event-stream resolver**, which returns the source event stream. 2. Per event it is resolved again, this time by an **ordinary field resolver** whose parent value is that event, producing the value that appears under the field's response key in the result. Step two is easy to forget because the event feels like it *is* the payload. It is not: it is the parent the payload is resolved from. If the server provides no explicit resolver for that root field, the widespread fallback reads a property with the field's name off the parent object. ## The half-empty result, and why it is silent On a translation-memory graph, the subscription is `segmentTranslated(projectId:)` and the publisher emits one record per translated segment. Publish this and everything works: ```json { "segmentTranslated": { "segmentId": "seg-88213", "matchScore": 0.94 } } ``` Publish the bare record instead — `{ "segmentId": "seg-88213", "matchScore": 0.94 }` — and the lookup for a property named `segmentTranslated` finds nothing, the field resolves to `null`, and every subscriber receives: ```json { "data": { "segmentTranslated": null } } ``` A response that arrives half-empty with **no errors entry at all**, because a nullable field resolving to null is a perfectly legal result, not a failure. Events flow at the right rate, the transport is healthy, dashboards are green, and every payload is empty. The fix is either to publish events keyed by the field name or to give the root field an explicit resolver that maps the event to the payload — the second is the more honest design, because it stops the wire shape of your internal events from dictating your schema's field names. ## Thin events versus fat events Because the event is only a root value, you get a real design choice. A **fat event** carries the whole payload. Execution below the root is then mostly reading properties off it, so per-event cost is low and predictable — attractive when you are holding a 340 ms p99 from publish to delivered result. The cost is coupling: every field a subscriber might select has to be in the event at publish time, and the publisher now has to know your schema. A **thin event** carries an identifier and enough context to filter — say `{ segmentId, projectId }`. Resolvers below the root load the current state. Now each subscriber's own selection set decides what is fetched, authorization runs in the resolvers per subscriber rather than at publish time, and a subscriber who selects three fields does not pay for thirty. The cost is that every event is a real fetch, so a burst of events is a burst of backend work, and two subscribers to the same event do that work twice unless per-request batching collapses it. Note also that a thin event resolves *current* state, so a rapid sequence of changes can deliver the same latest value twice rather than the two intermediate ones. ## Details worth having ready The per-event execution is a normal, non-serial selection-set execution — the serial rule belongs to mutation root fields, not to subscription events. Variables are the ones supplied when the subscription was created; there is no per-event variable set. And the response key rules are ordinary: an alias on the root field changes the key in every event's `data` map without changing which event stream was opened.