In a federated graph, why can one subgraph's failure erase data other subgraphs returned?

## Two independent mechanisms meeting The first mechanism is plain GraphQL: a field error nulls its field, and a null in a Non-Null position cannot stand, so it propagates to the nearest nullable ancestor; if every ancestor up to the root is Non-Null, the whole `data` value becomes null. The second is federation: one field's value comes from one process and its sibling's from another, and those processes fail independently. Each mechanism is unremarkable alone. Put them together and you get the response that surprises people: an 11-service legal case-file graph where the least important service takes the most important data down with it. ## The concrete shape **Cases** owns the type: ```graphql type Case @key(fields: "id") { id: ID! caseNumber: String! parties: [Party!]! } ``` Months later the **Conflicts** team — a different team, a different deployment, a different on-call rota — contributes one field to the same type in its own subgraph schema: ```graphql type Case @key(fields: "id") { id: ID! @external conflictCheck: ConflictCheck! } ``` They wrote `ConflictCheck!` for an honest reason: every case really does have a conflict-check record, so the field is never legitimately null. But `!` in GraphQL is not a statement about the data. It is a promise about the *response*, and the only way to keep it when the value cannot be fetched is to delete the parent. Conflicts times out. The client asked for `caseNumber`, `parties` and `conflictCheck`. Cases and Parties both answered in under 200 ms. The router still has to return: ```json { "data": { "case": null }, "errors": [ { "message": "Subgraph request failed", "path": ["case", "conflictCheck"] } ] } ``` A response that arrives half-empty is the good outcome. This one arrives empty, and the router was holding the caseNumber the whole time. ## Why the router cannot paper over it Three escape routes people propose, and why none exists. There is no default value for an output field — GraphQL defines defaults only for input arguments and variables, so the router has nothing to substitute. It cannot demote `ConflictCheck!` to nullable at runtime, because the client-facing schema is the contract every generated client type was built from; a null there would break callers that were told it could not happen. And it cannot omit the key, because a Non-Null field that was selected must appear with a value. ## Lists make it sharper `deadlines: [Deadline!]!` on `Case`, contributed by a **Deadlines** subgraph, has two `!` marks doing different jobs. The inner one says no element may be null: one bad element nulls the whole list. The outer one says the list itself may not be null: so a nulled list climbs into `Case`. A single unresolvable deadline in a list of 47 therefore erases the case node — an effect nobody intends when they type the wrapper out of habit. `[Deadline]` and `[Deadline!]` and `[Deadline]!` all fail differently, and on a cross-service field the choice is an availability decision, not a style one. ## Why this is a federation problem specifically In a single server, a Non-Null field and its parent usually fail together anyway: same process, same database, same outage. The `!` costs little. Across a composed graph the assumption breaks. The failure domains are genuinely separate — that separation is the entire reason for splitting the graph — and a `!` written in one subgraph silently re-couples them. Composition checks the field's *type* against other subgraphs; it does not and cannot tell you that Conflicts at 99.2% availability just capped `Case` at 99.2%. With eleven services contributing to a handful of core types, availability multiplies. Ten enrichment fields, each Non-Null, each on a service that is up 99.5% of the time, give a core type worse availability than any single service in the graph. ## The design rule A field is only as Non-Null as the reliability of the service that fills it. Keep `!` for fields the owning subgraph resolves locally from its own store — an entity's own identifier, its own name. At an ownership seam, make the contributed field nullable, and let its *inner* structure be strict: `conflictCheck: ConflictCheck` where `ConflictCheck` itself has non-null fields is both honest and safe, because a failure now leaves one hole instead of a crater. Enforce it at review time rather than by exhortation: a schema check that flags a Non-Null field added to a type the subgraph does not own catches this in CI, where fixing it is free. ## Diagnosing it after the fact When `data` comes back null with a single error, read the error's `path`. Its last segment is the field that failed; every segment before it is a level that got erased on the way up. That is the whole diagnosis: the depth of the path tells you how much collateral there was, and the field at the end tells you which team to talk to.