How does a GraphQL executor complete a list-typed field when one item cannot be completed?

## A list type is a wrapper, not a value `[Artwork!]!` is not a type that a resolver returns; it is three instructions to the executor wrapped around one type. Read outward-in: the field itself must not be null, its value is a list, and no item in that list may be null. The resolver knows none of this. It returns a collection, and value completion applies the wrappers. When completion reaches the list wrapper it does two things. **First, it demands a collection.** The specification is blunt here: if the resolved value is not a collection of values, a field error is raised for the field. There is no coercion of a single value into a one-item list and no treatment of a map as a list of its entries. Returning one object where a list was declared is a bug that surfaces at execution, not a convenience the executor absorbs. **Second, it completes each item against the inner type, independently.** Every item goes back through the whole completion ladder for the inner type - Non-Null, null, nested list, leaf, or composite with its own sub-selection. Item completion is per item: one item being an object with a failing child field says nothing about its neighbours. ## Paths carry the index While completing, the executor tracks the position it is at as a path: a sequence of response keys from the root, with a **0-indexed integer** for every list position it has descended into. That path is what a field error records, which is why error paths for list fields contain numbers: ```json { "errors": [ { "message": "Cannot return null for non-nullable field Artwork.accessionNumber", "path": ["gallery", "artworks", 5317, "accessionNumber"] } ] } ``` On an accession export page of 8,400 artworks, that path is the difference between a bug report and a shrug: it names item 5,317 specifically, and if the failing field had been requested under an alias, the path would carry the alias, because paths are built from response keys rather than schema field names. ## Order is a promise; sequencing is not The response list must be in the same order as the source collection. That is a promise about the *result*, not about the *schedule*: an executor is free to complete items concurrently, and most non-trivial servers do, as long as it writes each completed value back at its own index. So an item at index 8,399 may well finish before index 0; nothing about the response reveals that. ## What one bad item costs This is where the item-level Non-Null earns its keep, and where the two common list types diverge sharply. With `[Artwork]` - a nullable item type - an item that fails completion becomes null in place. The list keeps its length, the other 8,399 entries stand, and the errors entry names the index. With `[Artwork!]` - a non-null item type - the same failure raises at that index, and the null it would have produced is not a legal value for that position. The error is therefore raised for a position that cannot hold it and the effect climbs out of the list; the list itself is what goes null, and 8,399 successfully completed items are discarded with it. The raising is what value completion does; how far the resulting hole climbs and where it settles is the nullability question that follows from it. That asymmetry is the whole practical argument in the interview. `[Artwork!]!` reads as the strictest and most honest declaration - a list that always exists and never contains holes - and it is also the declaration under which one flaky item on a large page can take the entire page with it. A team paginating a collection graph at 8,400 rows per page has a real decision to make between "a guaranteed dense list" and "a page that degrades one row at a time", and the decision lives entirely in where the exclamation marks go. ## Empty is not null One last distinction that interviewers like to probe: an empty list is a perfectly good completed value. `[]` satisfies `[Artwork!]!` - there is no item to be null, and the list itself is not null. A field that returns "no rows" should return an empty collection, and a resolver returning null for `[Artwork!]!` because it found nothing is producing an error where it meant to produce emptiness.