In a GraphQL response, how do you tell a legitimately null field from one nulled by an error?

### One representation, two very different causes In a GraphQL response body, a missing value is written as JSON `null`, and there is exactly one `null`. It is used both for a value a resolver deliberately returned — a course with no assigned instructor yet, a student with no advisor — and for a hole the execution engine punched where a field error occurred. Nothing in `data` itself tells the two apart: there is no marker byte, no sentinel object, no flag on the parent. A client that wants to render "not set yet" differently from "we could not load this" has to reconstruct the distinction, and the only material available is the top-level `errors` list. ### The rule: prefix, not equality Each errors entry carries a `path` whenever the failure can be attributed to a field in the result — the sequence of response keys from the root of `data` down to the field that raised the error, with 0-indexed integers for list positions. The naive correlation is to look for an error whose path is exactly the position of the null you are inspecting. That is right only in the simplest case. When the field that failed is declared Non-Null, the engine cannot write `null` into that position, so the null appears **higher up**, at the nearest nullable ancestor, and everything below that ancestor — including sibling fields that had resolved perfectly well — is gone from the response. The error's path still names the deep field that actually broke. So the null you are staring at sits at an *ancestor* of the error path. That gives the reading rule a client should implement: > A `null` at response position `P` is failure-caused if some error entry's `path` **starts with** > `P` (which includes the case where the path equals `P`). If no error path starts with `P`, that > null is a value the resolver returned. Entries that carry no `path` at all are a separate bucket: they are not attributable to a position in the tree, so they can never explain a specific null and should be surfaced as a whole-operation problem rather than pinned onto a widget. ### A worked example An enrolment client requests one enrolment with its student and its section: ```json { "data": { "enrollment": { "id": "ENR-4471", "student": { "name": "R. Ibarra", "advisor": null }, "section": { "code": "STAT-101-B", "instructor": null } } }, "errors": [ { "message": "Instructor directory unavailable", "path": ["enrollment", "section", "instructor", "name"] } ] } ``` Two nulls, two different meanings. `["enrollment", "student", "advisor"]` is not a prefix of the single error path, so it is a real null — this student has no advisor assigned. The UI should render an empty state, an "assign advisor" affordance, whatever the product says an unassigned advisor looks like. Showing an error there is wrong and will generate support tickets about a system that is working. `["enrollment", "section", "instructor"]` **is** a prefix of the error path, so that null is a hole: the instructor's `name` is Non-Null, its resolver failed, and the null propagated up to the nullable `instructor` field, taking the rest of the instructor object with it. The UI should render "instructor unavailable", and the client should log the path. ### Implementing the check ``` function isErrorHole(nullPath, errors): for e in errors: if e.path is absent: continue # not attributable to a position if length(e.path) < length(nullPath): continue if e.path[0 .. length(nullPath) - 1] == nullPath: return true return false ``` Two details matter in practice. First, path elements are heterogeneous — strings for response keys, integers for list indices — so compare element-wise rather than joining them into a dotted string, where the key `"1"` and the index `1` would collide. Second, the response key is the **alias** when the document used one, so the path follows the shape of the response the client asked for, not the schema's field names. ### The third case: absent A key that was never selected is not present in the response map at all. In a dynamically typed client, reading it yields undefined/missing rather than `null`, and conflating that with a null is a common bug — it usually shows up when a fragment is conditionally included and the code treats "we did not ask" as "there is nothing there". Absent, null, and null-with-an-error are three distinct outcomes and deserve three distinct code paths. ### Why an interviewer asks this It separates candidates who have only read GraphQL responses in a playground from those who have written the boundary layer that turns one into view state. The prefix rule is the compact proof that you understand both what a path points at and what happens to a null when a Non-Null field fails — without which a client either shows error banners over perfectly ordinary empty data, or silently renders holes as if nothing went wrong.