In GraphQL, when does one failing list element null the entire list?

## The question behind the question "Does one bad row poison the whole list?" has a precise answer, and it is not a runtime decision or a server setting. It is decided by **which of the two wrappers on a list field is Non-Null**: the one around each element, or the one around the list itself. Those are independent, and they answer two different questions. * The **element** wrapper answers: *may an individual slot hold null?* If it may, a failing element leaves a null in place and the list survives. * The **list** wrapper answers: *may this field hold null instead of a list?* If it may, a list that has been destroyed can be replaced by null there and propagation stops. If it may not, the error keeps climbing into the parent object. Read them separately and every case falls out mechanically. ## Completing a list value When execution completes a value against a list type, it walks the entries in order and completes each one against the **inner** type. Each entry is its own propagation site: * An entry completes to null and the inner type is nullable → the response gets `null` at that index and the walk continues. The list keeps its length; the failure is contained in one slot. * An entry completes to null and the inner type is Non-Null → a field error is raised at that index, and it propagates to **the list**. There is no null-shaped slot available, and a list cannot quietly shrink, so the entire list becomes null. * Once the list itself is null, the ordinary rule takes over: if the list field is nullable, null sits there and propagation stops; if the list field is Non-Null, the error climbs into the parent object and keeps going. The crucial move is the second one. Nothing about the failure got worse — one seat's price lookup failed — but the list has no way to represent a missing element, so the only representable outcome is no list at all. ## Why the list never shortens A common wrong answer is that the failing element is skipped and the list comes back one shorter. Execution never does this, and the reason is that indices are meaningful. Clients page, key and render by position; an error entry's `path` addresses list positions by 0-indexed integer. Silently compacting a list would move every element after the failure and make every recorded index a lie. So the choices are exactly two: a null in place, or no list at all. ## The nesting most people miss The failure does not have to be the element itself. It is far more often something *inside* the element. That runs in two stages: 1. Inside the element, ordinary propagation applies. A Non-Null field on the element errors, the error climbs the element's own fields, and if it reaches the element object with nothing nullable to absorb it, the element completes to null. 2. Only now does the element wrapper matter. Nullable element → a null at that index, list intact. Non-Null element → the error escapes into the list, and the list dies. So a `priceCents: Int!` failing on one seat can blank a whole section's seating — not because the list is fragile, but because the failure was promoted from a field, to the element, to the list, one Non-Null wrapper at a time. ## Worked example on a venue graph ```graphql type Section { name: String! seatsStrict: [Seat!]! # element Non-Null, list Non-Null seatsTolerant: [Seat]! # element nullable, list Non-Null } type Seat { id: ID! row: String! priceCents: Int! } ``` A pricing lookup fails for exactly one seat in a section of 1,842. * Selecting `seatsStrict` — the seat completes to null, the element wrapper refuses it, the list becomes null, the list wrapper refuses *that*, and the error lands on `Section`. Every one of the other 1,841 seats is discarded, along with `name`. * Selecting `seatsTolerant` — the seat completes to null, the element wrapper accepts it, and the client receives 1,842 entries of which one is `null`, alongside a single error whose `path` ends in the index of the bad seat. `name` survives. Same failure, same depth, two completely different responses. ## Reading it from the outside From a client's point of view the diagnostic signal is simple. A null **at an index** means the element wrapper was nullable and exactly that element failed. A null **where a list was expected** means an element was Non-Null and one entry took the list down with it — and the count of errors still does not tell you how many elements failed, because propagation stops the walk. The originating error's path is the only thing that names the real culprit. ## The judgement, briefly Element nullability is a decision about how much of a collection one bad row may destroy, and tolerant elements buy containment at the cost of a null branch in every client that renders the list. That trade is a schema-design call and is made once, in the type, long before the failure.