In GraphQL introspection, why is __Type.name null for a field typed [Artwork!]!, and how do you read it?

## Two kinds of type, one record shape GraphQL's type system has **named types** — scalars, objects, interfaces, unions, enums and input objects — and **wrapping types**: list and non-null. Introspection represents both with the same `__Type` record, and tells them apart with the `kind` field, whose value comes from the `__TypeKind` enum: `SCALAR`, `OBJECT`, `INTERFACE`, `UNION`, `ENUM`, `INPUT_OBJECT`, `LIST`, `NON_NULL`. The first six are named. The last two are not: a list of somethings has no name of its own, and neither does "a something that cannot be null". So for a `LIST` or a `NON_NULL` record, `name` is `null` and `ofType` points at the type being wrapped. For every named kind the reverse holds: `name` is set and `ofType` is `null`. That is the whole answer to why `name` comes back null. A field declared `[Artwork!]!` is not one type called `[Artwork!]!`; it is four nested records, and only the innermost one has a name. ```json { "name": "artworks", "type": { "kind": "NON_NULL", "name": null, "ofType": { "kind": "LIST", "name": null, "ofType": { "kind": "NON_NULL", "name": null, "ofType": { "kind": "OBJECT", "name": "Artwork", "ofType": null } } } } } ``` Read outside-in, that says: non-null list, of non-null `Artwork`. Every consumer of introspection — anything that prints a type, generates code, renders documentation or compares two schemas — must walk that chain rather than read `name` at the top. Code that reads `field.type.name` and prints it works fine on the handful of bare, nullable fields in a schema and produces `null` everywhere else, which is exactly the shape of the bug reports this generates. ## The unwrapping algorithm ```pseudocode function renderType(t): if t.kind == "NON_NULL": return renderType(t.ofType) + "!" if t.kind == "LIST": return "[" + renderType(t.ofType) + "]" return t.name function namedTypeOf(t): while t.ofType != null: t = t.ofType return t ``` Two helpers, and almost every real consumer needs both: one to display the type faithfully, one to answer "which named type is ultimately involved here?" — the question you ask when resolving references between types. ## Why introspection queries unroll a fixed depth Here is the part that catches people. The chain is recursive, but a GraphQL **executable document is not**: a selection set is written out literally, and a named fragment may not spread itself, directly or transitively. There is no way to write "follow `ofType` until it is null". So an introspection query hand-unrolls the chain a fixed number of levels — the canonical shape used across the ecosystem unrolls about seven — and anything nested deeper than the unrolled depth is truncated to `null`. ```graphql query FieldTypes { __type(name: "Gallery") { fields { name type { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } ``` Seven levels is not an arbitrary comfort margin. Wrapper nesting is bounded in practice because `NON_NULL` may not wrap `NON_NULL` — `Artwork!!` is not a valid type — so the chain only lengthens when lists nest. A bare named type is one record, `[Artwork!]!` is four, and a doubly nested `[[Artwork!]!]!` is six. Seven levels therefore covers three levels of list nesting, which no sane schema exceeds. But the truncation is silent: a consumer that hits the floor sees a `__Type` with a null `name` and a null `ofType` and cannot tell that apart from a malformed response, so a type-rendering routine should treat that state as an explicit error rather than printing an empty string. ## Why the representation is shaped this way The alternative design — a named type plus boolean `isList` and `isNonNull` flags — cannot express the distinction GraphQL cares most about. `[Artwork]!`, `[Artwork!]` and `[Artwork!]!` are three different contracts about where a null may appear: in the list, instead of the list, or nowhere. Two booleans give you four combinations and no way to talk about the *inner* nullability of a nested list. The wrapper chain expresses arbitrary nesting exactly, at the cost of making every consumer write the loop. ## Watch for * Reading `name` off a field's type and reporting the server as broken when it is null. * Believing `[Artwork!]!` is a single named type somewhere in `__schema.types`. * Expecting to traverse `ofType` recursively in one document. * Thinking `NON_NULL` can wrap another `NON_NULL`. * Rendering the chain inside-out, and producing `[Artwork]!!` or similar nonsense.