For a GraphQL list whose elements each come from a call that can fail, which nullability wrapper do you choose?

## Two decisions, not one A GraphQL list type wraps another type, and each of the two positions can independently be Non-Null. That gives four shapes, and the reason interviewers like this question is that most candidates read them as a single slider from *loose* to *strict* rather than as two separate answers to two separate questions. * `[BenefitElection]` — the list may be null, and any element may be null. * `[BenefitElection!]` — the list may be null, but if it is present, every element is a real object. * `[BenefitElection]!` — the list is always present, but individual entries may be null. * `[BenefitElection!]!` — the list is always present and every entry is a real object. The first question is about the collection: **can the collection as a whole fail to be produced?** The second is about the entries: **can one entry fail while its neighbours succeed?** Answer both from how the data is actually fetched, and the wrapper writes itself. ## Why a Non-Null element is a blast radius decision If elements are Non-Null and one of them cannot be produced, there is nowhere in that list to put the failure. The list position is not simply skipped — a list value has one completed value per element position, and nothing in GraphQL lets a server return a shorter list because an entry misbehaved. The unfulfillable Non-Null element therefore takes the list with it, and if the list is Non-Null too, the loss keeps travelling to the nearest nullable ancestor above. So `[BenefitElection!]!` on a field whose elements are fetched one call each is a statement that one employee's unreachable benefits provider is worth the whole collection — and, because the list is Non-Null as well, worth whatever sits above it. That is almost never what the author meant. ## Choosing per field in a payroll and benefits graph ```graphql type Payslip { id: ID! # one lookup per election against the benefits provider; # a single unreachable plan must not lose the rest benefitElections: [BenefitElection]! # loaded in the same query as the payslip row: all of them or none taxWithholdings: [TaxWithholding!] } ``` `benefitElections` is always present as a list — the server knows how many elections the employee has — but an individual plan lookup can time out, so entries are nullable. A hole appears at the failing index, an error entry names that index in its path, and the surviving elections render. `taxWithholdings` comes back with the payslip row in a single query. There is no way for entry three to fail while entries one and two succeed; either the query answered or it did not. So the elements are Non-Null and the list is the nullable position — nullable elements there would be dishonest, forcing every consumer to check for a null that the server can never produce. ## The cost side Nullable elements are not free. Every consumer of `[BenefitElection]!` must decide what to do with a hole: skip it, render a placeholder row, show a partial-data banner. A typed client generator will emit the element as optional, and that optionality spreads through the calling code. If a list's entries genuinely cannot fail independently, marking them nullable buys nothing and taxes everyone. There is also an ambiguity cost, the same one every nullable position carries. A null entry may mean *this election could not be loaded* or, less commonly, that the server deliberately placed an empty slot there. Only an error entry whose path names that index distinguishes the two, so a consumer that ignores the errors list will silently under-report. ## What is specified and what is convention The four wrappers and their meanings are part of the type system, and the rule that an unfulfillable Non-Null element propagates outward rather than shortening the list is specified behaviour. What is **not** specified is which wrapper your field should use. "Non-Null elements, nullable list" is a common house style, and so is its opposite; both are convention. The defensible answer in an interview is not a preferred shape but a rule for deriving the shape from the fetch pattern — collection-level failure decides the list, element-level failure decides the element. ## A quick review heuristic When reviewing a schema, look for `[T!]!` on any field whose resolver loops over entries and calls something per entry. That combination is the highest-blast-radius list shape there is: one entry's failure erases the collection and then keeps going. It is correct when the collection is genuinely atomic, and a latent outage when it is not.