Null Propagation and Bubble-up Rules

One Missing Author, One Empty Screen

The schema looks reasonable enough that nobody argues about it in review:

type Query {
  post(id: ID!): Post!
}
type Post {
  id: ID!
  title: String!
  author: Author!        # every post has an author, right?
}
type Author {
  id: ID!
  name: String!
}

Then someone soft-deletes an account. The join returns null, the resolver returns null (or throws), and the client receives this:

{
  "data": null,
  "errors": [
    {
      "message": "Cannot return null for non-nullable field Post.author.",
      "path": ["post", "author"]
    }
  ]
}

Not "author missing" — everything missing. The leaf failure climbed three declarations and erased the response. A row being deleted in one table turned into a blank screen for a query that also asked for title, which resolved perfectly.

This is the behavior the specification calls null propagation, and it is deterministic: a null produced where the schema says null is impossible gets passed upward until it lands somewhere the schema allows null, or until it reaches the root and takes data with it. Nothing about the failure is mysterious, which means you can predict it exactly — and you should, because every ! you type is a promise that a future data state has to keep.

The design question this topic exists to answer: where do you place that promise? Mark everything non-null and one bad join blanks the screen; mark everything nullable and every client drowns in null checks. The boundary between them is a deliberate engineering decision about which failures users are allowed to see.

How the Null Actually Travels

The rule in one sentence: when a field produces null but its type is non-null, the null is handed to the parent field, and the process repeats until it reaches a nullable field — or the response root.

Trace it against the schema above. The resolver for author returns null; author: Author! forbids it, so an error is recorded with path: ["post", "author"] (the position of the failing field, not where the null stopped) and post's value becomes null. But post: Post! forbids that too, so the null climbs once more, to the root. data accepts null, the climb ends:

Query.post: Post!              <- null not allowed: climbed past
 └─ Post.author: Author!       <- resolver returned null (error raised HERE)
     └─ Author.name: String!   <- never ran; its branch is discarded

Three details separate people who have read the spec from people who have only used it:

1. A null on a nullable field is data, not an error. If author: Author and the resolver simply returns null, no entry appears in errors at all. Errors arise only when a resolver throws or produces null for a non-null field. "The field is null" and "the field failed" are different statements.
2. Independent branches keep their data. Execution finishes unrelated selections before the response is assembled, so a failure under post does not touch a sibling top-level field. The blast radius is the ancestor chain of the failing field — nothing wider — unless that chain itself reaches the root.
3. List indices are positions, not names. With posts: [Post!]!, the first item's failure propagates through the list container: an element cannot be null, so posts itself becomes null, and then whatever type posts has decides the next hop.

Because the algorithm is pure bookkeeping over the type tree, a trace exercise is mechanical: start at the failing resolver, look at the declared type, and repeat until you hit a nullable declaration or data.

Drawing the Nullability Boundary on Purpose

Each ! is a claim about the future. Write them where the data layer guarantees the claim, and leave them off where reality can break it.

What non-null should mean: the value comes from a single row with a NOT NULL constraint, an identifier the server itself minted, or a computation that cannot fail. Post.id, Post.title (if the column is required), a count computed from an in-memory list — those promises hold.

What belongs in nullable territory:

• Joins and lookups that reference soft-deletable rows — exactly the author case.
• Anything served by another team, another service, or a federation boundary where the remote may answer late or not at all.
• Computed or user-generated content: a derived ranking, an oEmbed expansion, a profile headline that may not exist yet.
• List items whose individual failure should not cost the whole list.

Nullability of list members deserves its own decision, because the two dimensions fail differently:

Two operational habits complete the picture:

Make failures loud. Returning null for a non-null field is already an error — the server records one — but a bare "cannot return null" tells an on-call engineer nothing about which resolver or which row. Throwing a GraphQLError carrying a code and a correlation id converts the same situation into something diagnosable. Reserve the bare return for cases where you genuinely do not know more.

Test the promise. A schema assertion like author: Author! is an invariant; invariants deserve a test that simulates the missing row and asserts the response shape you predicted. Teams that write these tests discover their accidental non-null chains during CI instead of during an incident.

Interviewers ask this question almost verbatim: "what happens when a non-null field returns null?" The complete answer names the algorithm (propagate to the nearest nullable ancestor), the endpoint (or data: null at the root), the side conditions (sibling branches unaffected; a nullable null raises no error), and the design lever (moving the ! one level down changes the blast radius from the whole response to one subtree).