Why can't one GraphQL subscription operation watch two event streams at once?

## The rule The GraphQL specification carries a validation rule for subscription operations: the fields collected on a subscription's root selection set must number **exactly one**, and that one field must not be an introspection meta-field. It is a static rule, checked before execution, and it applies to subscription operations only — a query or a mutation may select as many root fields as it likes. So this is invalid: ```graphql subscription ClinicFeed($clinicId: ID!) { slotReleased(clinicId: $clinicId) { id startsAt } appointmentCancelled(clinicId: $clinicId) { id reason } } ``` The restriction is on **root** fields. Nesting below that single root field is unrestricted: `slotReleased` can return an object whose selection set is five levels deep with a dozen fields at each level, and the rule is untroubled. ## Why one Because the root field *is* the stream. Setting up a subscription resolves that one root field to a source of events, and every subsequent result the client receives is produced by executing the rest of the selection set against one event drawn from that source. One operation therefore maps to one source. Two root fields would mean two independent sources arriving on one operation, and the specification would then have to answer questions it deliberately never asks: what a result looks like when only one source has fired, whether the other field's key appears with a null, what happens when one source ends and the other does not, and how the two are ordered relative to each other. The introspection exclusion follows from the same idea. Introspection meta-fields describe a static schema; there is no source of events behind them, so `subscription { __typename }` has nothing to stream and is rejected rather than being allowed to hang. ## The count happens after fragments flatten The rule counts the fields *collected* on the root, which means fragment spreads are flattened first. So this is invalid too, for exactly the same reason as the two-field version: ```graphql subscription ClinicFeed($clinicId: ID!) { ...Releases ...Cancellations } fragment Releases on Subscription { slotReleased(clinicId: "c-3319") { id } } fragment Cancellations on Subscription { appointmentCancelled(clinicId: "c-3319") { id } } ``` Two spreads, two collected root fields, validation failure. This trips people who assume the check is a syntactic count of the braces they typed. It is not — it is a count over the flattened field set, which is why an interviewer who wants to separate 'has read the rule' from 'has understood the rule' asks the fragment version. ## The design fork when you genuinely need two streams A client on a hospital appointment graph that needs both slot releases and cancellation notices has two honest options, and choosing between them is schema design, not specification compliance. **Two subscription operations.** Each stream is its own operation with its own lifecycle. Consumers subscribe to only what they need, the two payload types evolve independently, and a consumer that cares about cancellations is not woken by every release. The cost is more concurrent subscriptions to manage — more server-side stream bookkeeping, more to re-establish after a disconnect, and a per-client footprint that grows with the number of event kinds. **One coarse root field carrying a union.** Declare something like `clinicEvents(clinicId: ID!)` whose type is a union of the event payloads, and let the client branch on the concrete type: ```graphql subscription ClinicFeed($clinicId: ID!) { clinicEvents(clinicId: $clinicId) { __typename ... on SlotReleased { slotId startsAt } ... on AppointmentCancelled { appointmentId reason } } } ``` One stream, one lifecycle, one reconnect to handle. The cost is coupling: every consumer receives every event kind on that field and discards most of them, adding an event variant is a change to a type that all of them read, and a chatty variant's volume is now paid for by consumers that do not want it. Neither is 'correct'. The coarse union is a good fit when the events genuinely belong to one logical feed that a single view renders; two operations are a better fit when the consumers are different screens with different appetites. What the specification settles is only that you must choose one of them — you cannot avoid the decision by stapling two root fields onto one operation.