What happens in GraphQL when a resolver for a Non-Null field raises an error?

## The rule in one line A field typed as Non-Null has promised the caller that it will never be `null`. When the value behind that field fails to materialise, execution cannot keep the promise and cannot break it either, so it does the only remaining thing: it destroys the container. The **field error propagates to the parent field**, and it keeps propagating until it reaches a field that is allowed to be null. ## Two ways a Non-Null field goes wrong They differ in origin and are identical afterwards. 1. **The resolver fails.** It throws, rejects, or otherwise signals failure. That is a field error at that position. 2. **The resolver succeeds and returns `null`.** The executor still raises a field error, because a `null` cannot be serialized into a Non-Null position. No exception was thrown anywhere; the server manufactures the error itself, and the message it writes is implementation-defined. Candidates routinely know the first case and are surprised by the second. A resolver that quietly returns `null` for a Non-Null field is not a silent no-op — it produces exactly the same crater. ## How propagation actually runs Execution resolves a field to a raw value and then **completes** that value against the field's declared type: unwrapping list and Non-Null wrappers, serializing leaves, recursing into selection sets for object types. Completion is where the check lives. * If the completed value is `null` and the field's type is nullable, the response gets `null` there and execution carries on. This is not an error and produces no `errors` entry. * If the completed value is `null` and the field's type is Non-Null, a field error is raised **at that position** and handed to the parent field. * The parent now behaves as if *it* had resolved to `null`. If the parent's own type is nullable, it becomes `null` in the response and propagation stops. If the parent's type is also Non-Null, the error is handed to *its* parent, and so on. * If every field from the root down to the originating field is Non-Null, propagation runs out of ancestors, and the `data` entry of the response is `null`. The stopping point is therefore not a policy choice made at runtime. It is decided entirely by where the nearest nullable field sits on the path from the root to the failure. ## One error, not one per level This is the detail interviewers probe. The specification says at most one error is added to `errors` per field, and propagation itself adds nothing. A failure four levels deep that nulls three ancestors still yields **one** entry, describing the field where the error originated. The ancestors that were blanked leave no trace of their own — the only evidence they were involved is the `null` sitting in the response where the client expected an object. ## What is lost on the way Nulling a parent takes that parent's entire selection set with it, not just the failing field. Root fields and sibling fields of a query may be executed concurrently, so several of those siblings may have already resolved successfully by the time the error propagates. Their results are discarded anyway; there is no partial object with a hole in it, because a hole would require the object to still exist. ## A worked example on a ticketing graph ```graphql type Query { event(id: ID!): Event } type Event { id: ID! title: String! venue: Venue! # Non-Null seatMap: SeatMap # nullable } type Venue { id: ID! name: String! seatingChartUrl: String! # Non-Null, backed by a slow asset service } ``` An operation selects `event { title venue { name seatingChartUrl } seatMap { sections } }`. The asset service times out, so `seatingChartUrl` raises a field error. It is Non-Null, so the error goes to `venue`. `venue` is Non-Null on `Event`, so it goes to `event`. `Query.event` is nullable, so propagation stops there: the response is `"data": { "event": null }` with a single `errors` entry. `title`, `name` and the whole `seatMap` sub-tree resolved fine and are gone. The client asked for a page and got a null and one message about an image URL. Change one thing — make `Query.event` return `Event!` — and the same failure nulls `data` itself, taking any other root field in the same operation with it. ## Why the design is like this Non-Null is what makes a generated client type honest: if the schema says `String!`, the client's type for it has no null branch and no null check. Propagation is the price of that honesty. The alternative — writing `null` into a Non-Null position — would hand clients a value their own type system says is impossible, and the failure would surface as a crash somewhere far from the cause. Two consequences worth saying out loud. Propagation is a rule about the **shape of the response**, not a transaction: nulling a value does not undo work the server already performed. And the reach of any single failure is fixed by the schema long before the failure happens, which is why nullability is treated as a design decision rather than a stylistic one.