In a GraphQL response, how does an absent data key differ from data present with the value null?

## Two states, one nullish value The response envelope gives `data` three possible states, not two: 1. **Absent.** There is no `data` key in the response map. 2. **Present, null.** There is a `data` key and its value is the JSON value `null`. 3. **Present, a map.** The ordinary case, possibly with holes in it. Most people internalise states 2 and 3 and never notice state 1, because almost every JSON deserializer and almost every typed client models `data` as a single nullable field. A missing key and an explicit null both land as the same nullish value, and the distinction is gone before any application code runs. The envelope draws that distinction deliberately, and it carries real information. ## What each state tells you **`data` absent** means the operation was never executed. The server rejected the request before execution began — it could not parse the document, the document did not validate against the schema, or a variable value could not be coerced into its declared type. Because execution never started, no resolver ran, no backend was called, and no write happened. The `errors` list is present and describes why. **`data` present and null** means the opposite: execution began. The server resolved fields, and somewhere in that process the result became unusable at the root, so the whole result serialized as null rather than as a map. The work done up to that point still happened. Any resolver that already ran, ran; anything it wrote, it wrote. That is the whole point of the distinction. Absent means *nothing happened*. Null means *something happened and you are not being shown it*. ## Where this bites: the retry A four-person platform team runs a music catalogue graph. Their shared client wrapper has a plausible-looking helper: ``` if (response.data == null) { retryOnce() } ``` The intent was to survive request errors, which are usually transient in their environment. It works fine for queries. Then a `publishRelease` mutation starts returning a null `data` under load: the mutation resolver writes the release row, then the payload it returns contains a field the server cannot complete, and the failure reaches the root. The wrapper sees a nullish `data`, concludes the mutation did not happen, and sends it again. The second call writes a second row. Over nine days the team found 217 duplicate release rows, all traceable to a retry that fired against a response whose `data` was present-and-null rather than absent. The bug is not in the server and not in the schema; it is in a client that treated two envelope states as one. ## Checking it properly The check has to be on **key presence**, and how you spell that depends entirely on what your parser gives you: * A raw parsed map has a containment test — ask whether the key exists before asking what its value is. * Some languages can model the difference in the type system, with an optional wrapping a nullable, so an absent key and a null value are distinguishable values. * Many typed clients erase it. If yours models the response as one nullable field, you cannot recover the distinction downstream and must inspect the raw body before it is deserialized. The rule of thumb worth stating in an interview: **absence is safe to retry, null is not.** If `data` is absent, nothing executed, so re-sending is harmless — though re-sending an identical malformed or invalid document will simply fail identically, so the retry is pointless rather than dangerous. If `data` is present and null, execution ran and you must assume any side effects it could have had, it had. Recovering from that needs an idempotency key on the mutation or a read-back to check what actually landed, not a blind retry. ## Two things this distinction does not tell you It does not tell you *why*. The reason `data` came back null lives in the accompanying `errors` list, and the reason it was absent lives there too — the envelope only tells you which side of the execution boundary you are on. It also does not mean a null `data` implies a server crash. It is a defined, ordinary outcome of the execution rules, and a response carrying `"data": null` with a populated `errors` list is a perfectly conformant response, not a sign that anything is broken beyond the one failure being reported. ## The interview version Say the three states out loud, attach "execution never started" to absence and "execution ran" to null, and then give the consequence: a client that tests for nullness rather than key presence will retry operations that already took effect. That last sentence is what the question is actually probing.