Errors & Null Propagation

It means the schema declares the failure as its own type — a union member or an error field inside a payload — so the failure arrives under data as an ordinary selectable value instead of in the response's top-level errors list.

The field cannot hold null, so the error propagates to its parent. The parent becomes null if it is nullable; otherwise the error keeps climbing, and if every field up to the root is Non-Null, data itself becomes null.

A document can carry several root mutation fields. They run one after another, and nothing wraps the group in a shared transaction, so if the second one fails the first one's write has already committed and stays committed.

Execution ran and some fields failed while others resolved. The data object holds every field that succeeded, with null in the holes; each errors entry names the field that broke via its path. Both halves are real.

A request error happens before execution — the document failed to parse or validate, or its variables would not coerce — so nothing ran and there is no data entry. A field error is raised while resolving one field, leaving data partial.

Three, and no others: data, errors and extensions. The errors key appears only when something went wrong, and is then never empty. The data key is absent when the operation never executed. The extensions key is optional and free-form.

Leave a nullable field on the path between every risky field and the root. A value that cannot be produced for a Non-Null position is absorbed by the nearest nullable ancestor, so that ancestor is the boundary of the damage.

path lists segments running from the root of data down to the field: response keys as strings, and 0-indexed integers for positions inside list fields. Because it walks the response, an aliased field appears under its alias.

By selecting the __typename meta-field, which returns the name of the concrete object type, and by writing one inline fragment per member for that member's own fields. A default branch handles members the document does not cover.

When the element type is Non-Null. A failing element cannot be represented as null in place, so the error propagates to the list, which becomes null and may keep climbing. With nullable elements the list survives with a null at that index.

Check the errors list. A null a resolver deliberately returned has no error pointing into it; a null caused by a failure has an errors entry whose path is that position or runs deeper through it.

The direction of coercion decides. An enum value the schema does not declare is a request error when a client sends it, so nothing runs; it is a field error when a resolver returns it, nulling that field.

An absent data key means the operation never executed, so no resolver ran. A present data key whose value is null means execution did run and its result was discarded. Only the first guarantees nothing happened server-side.

Find the unbroken Non-Null chain from the failing field to the root, decide the smallest unit consumers can render without that field, and make the link at that boundary nullable. Then bound the dependency with a timeout so it fails fast into that hole.

Publish a small, stable, machine-readable code vocabulary inside extensions and have clients switch on that, never on the message string. Keep codes additive, require a default branch for unknown ones, and namespace anything beyond the code to avoid collisions.

Expected outcomes of a valid request that a client renders differently belong in the payload as schema types. Faults — timeouts, bugs, unavailable dependencies — belong in the errors list, where operators and generic client handling can see them.

Read the error's path: it names the field that actually raised, not the ancestor that was nulled. Then walk that path in the schema from the root; if every field on it is Non-Null, propagation reached the root and nulled data.

Have the client send a stable key it generates once per logical action and reuses on every retry. The server records that key with the outcome in the same transaction as the write, and on a repeat key returns the recorded result instead of writing again.

Stop treating the errors list as a verdict on the whole response. Render everything data resolved and use each error's path to degrade only the region over that hole. Reserve a full failure screen for a body with no usable data.

A request error is deterministic — the same document fails identically forever — so retrying is waste and the signal is a client or schema release. A field error is a transient dependency fault where a retry can succeed.

Write a rule that derives ! from where the data comes from — Non-Null only for values produced with their parent, nullable across any boundary — then enforce it with schema lint in the build and check it against per-field error rates.

Only where a failure is a durable business outcome that clients render distinctly. Apply it through one house carrier and a small shared failure vocabulary, because a graph carrying three inconsistent styles is worse than either style applied everywhere.

Make the field the atomic unit and enforce that at the boundary rather than in review: reject multi-write documents, require one idempotency convention across the graph, measure the rate of partially-applied mutation responses, and reconcile what genuinely cannot be atomic.

Make the elements nullable and keep the list itself Non-Null, as in [BenefitElection]!. A failed element leaves one hole beside an error entry; the successful elements survive, because a Non-Null element would take the whole list with it.

They point into the document text the client sent, marking the beginning of the relevant syntax element. Both numbers are positive integers starting at 1, and the entry is a list because one error can implicate several places.

Yes. A field error produces null for that one field and an entry in the errors list, and the executor then moves on to the next root field and runs it. There is no early exit, so later side effects still happen.

It is the one sanctioned place for anything a server sends beyond data and errors, because no other top-level entry is allowed. It must be a map when present, and a client may assume nothing about its contents.