Error Propagation in Resolvers

What the Client Sees When a Resolver Throws

Post: {
  author: async (post, _a, ctx) => {
    const rows = await ctx.pool.query(
      'SELECT id, name FROM users WHERE id = $1', [post.authorId]);
    return rows[0];   // the connection drops mid-query and this throws
  },
}

The executor catches the throw — a resolver crash does not take down the HTTP handler — and converts it into a field error alongside whatever data could still be produced:

{
  "data": { "post": { "title": "Resolvers", "author": null } },
  "errors": [
    {
      "message": "connect ECONNREFUSED 10.4.2.9:5432",
      "path": ["post", "author"],
      "locations": [{ "line": 3, "column": 5 }],
      "extensions": { "code": "INTERNAL_SERVER_ERROR" }
    }
  ]
}

Four properties worth internalizing:

• HTTP status stays 200. Execution errors are reported in the body; only malformed requests or failures before execution tend to change the status.
• Partial responses are valid results. title still resolved — errors and data ship together, and data is only null when the cascade reaches the top.
• path locates the failure as ["post", "author"], so clients, logs, and alerts can point at a field instead of parsing prose.
• locations refers to the document, which is useless for variable-driven inputs — path is what to log.

The item no bullet mentions is the one that bites: message came straight from the thrown error. The client receives whatever text the exception carried — SQL fragments, hostnames, connection strings — while extensions.code falls back to the generic INTERNAL_SERVER_ERROR because nothing classified it. Sanitizing and classifying that message is the third chapter.

Two more habits worth forming while reading responses. A single document can produce several entries: each failing field contributes its own, so three paths in errors means three distinct failures at three depths, never one summary. And this shape only exists once execution has started — a document that fails validation arrives with data absent entirely and no path on the error, because no field was ever reached.

Nullability Is the Bubbling Rule

Whether an error dies at one field or empties half the response is decided entirely by nullability.

The rule: a non-null field cannot represent failure as null, so the null propagates to the nearest nullable ancestor — and keeps climbing if that ancestor is non-null too.

Query.post: Post          nullable   ← stops the cascade
Post.author: Author       non-null
Author.email: String!     non-null   ← resolver fails here

error at ["post", "author", "email"]
  email  is String!  → cannot be null here, bubble up
  author is Author!  → non-null, keep bubbling
  post   is Post     → nullable, absorbs it

{
  "data": { "post": null },
  "errors": [
    { "message": "Internal", "path": ["post", "author", "email"] }
  ]
}

One leaf failure removed the entire post — including title, which had already resolved successfully. Lists follow the same logic: if a non-null subfield fails inside [Author!]!, the whole list goes null rather than growing a hole.

The design consequence is easy to state and hard to follow: non-null is a promise that the field always produces a value. Marking everything ! looks strict, but one failed dependency then blanks the response; leaving a leaf nullable preserves the data that did resolve. Deeper semantics live in null propagation semantics.

Sanitize, Classify, Control the Blast Radius

Sanitize. Never let raw exception text out:

// WRONG — SQL and infrastructure details become public
throw new Error('SELECT failed: ' + err.message);

// BETTER — detail stays server-side, clients get a stable message and code
ctx.logger.error({ err, requestId: ctx.requestId, path: info.path }, 'author lookup failed');
throw new PublicError('Author could not be loaded', { code: 'UPSTREAM_UNAVAILABLE' });

The contract to implement: message for humans, extensions.code for machines, everything else in logs keyed by the request id built in resolver context. Clients branch on codes, never on message strings.

Classify. Where an error belongs follows from who can act on it:

Control the blast radius. Error handling and schema design meet at nullability. If Post.author were declared non-null, the failed lookup in chapter one would have nulled the whole post; with Post.author: Author nullable, clients still render the title and show an author placeholder. Mark a field non-null only where a null value would be useless to the caller — every ! you write is a decision about how much of the response one failure may destroy.

Interview angle: an interviewer will hand you a schema with a failing deep resolver and ask for the response body. Walk the tree bottom-up applying the bubbling rule, state the resulting path, note that HTTP stays 200, then say what you logged and what the client was allowed to see.