How does a GraphQL error's path entry locate the failed field, and what do its integers mean?

## What path is for `path` is the entry in a GraphQL error that answers "**which field of the response is this about?**". Without it a caller holding a body with nulls in it has no way to attribute any of them; with it, every failure is pinned to an exact position. The specification is unusually firm here. `message` is required outright. `path` is required **whenever the error can be associated with a particular field in the result** — which is to say, for essentially every error raised during execution. Errors raised before execution begins (a document that would not parse, a document that failed validation) have no field to point at, and so carry no `path`. ## The encoding `path` is a **list of segments**, ordered from the root of `data` down to the field in question. Two kinds of segment exist and nothing else: * **Strings** — a field's key in the response. * **Integers** — a **0-indexed** position inside a list field. So a path like ```json ["warehouse", "bins", 4, "stockItems", 11, "reorderPoint"] ``` reads: inside the `warehouse` field, inside its `bins` list, the item at index 4, inside that item's `stockItems` list, the item at index 11, its `reorderPoint` field. Index 4 is the **fifth** bin. Off-by-one here is the single most common mistake made reading these in a log, and it is worth saying "index four, so the fifth" out loud in an interview. Nested lists nest their integers with no field name in between: a `List of List of Bin` produces two consecutive integers, `[..., 2, 0, ...]`. ## It is a path through the response, not through the document This is the part that separates a candidate who has read the specification from one who has guessed. The segments are **response keys**. When a document aliases a field, the alias is what appears in the response, so the alias is what appears in `path`: ```graphql query BinAudit { warehouse(id: "WH-7") { cold: bins(zone: FROZEN) { stockItems { reorderPoint } } dry: bins(zone: AMBIENT) { stockItems { reorderPoint } } } } ``` A failure inside the frozen zone produces `["warehouse", "cold", 0, "stockItems", ...]`. Not `bins`. The specification calls this out explicitly, and the reason is practical: aliasing exists precisely so the same schema field can appear twice in one response, and a path that reported the schema name could not tell those two occurrences apart. Since the entire job of `path` is to disambiguate a position in the response, it has to speak the response's own language. The same logic explains why `path` says nothing about types, arguments or the shape of the query. It is a coordinate in a JSON-shaped result and nothing more. ## What it is not * It is **not** a location in the document text. That is `locations`, which counts lines and columns from 1 while `path` counts list positions from 0. * It is **not** a stack trace. It names one field, not the chain of calls that failed inside the resolver. * It is **not** a pointer into the schema. Two different paths can name the same schema field, and a single path names exactly one response position. * It is **not** free-form. Only strings and integers are permitted as segments. ## Reading one in practice Suppose a warehouse dashboard's overnight replenishment job starts logging errors. Three entries arrive with paths ```json ["warehouse","bins",4,"stockItems",11,"reorderPoint"] ["warehouse","bins",4,"stockItems",26,"reorderPoint"] ["warehouse","bins",9,"stockItems",3,"reorderPoint"] ``` Two facts fall straight out without touching a resolver. The failure is field-scoped — always `reorderPoint`, never a sibling — so the fault lies with that one field's dependency rather than with bin loading. And it is spread across two bins and three different list positions, so it is not one poisoned row. That is a diagnosis reached from the error shape alone, in seconds, and it is exactly why interviewers ask about `path` rather than about `message`. ## Practical consequences for a client Because paths are stable, machine-readable and complete, they are the correct key for anything programmatic: deciding which part of a screen to mark as degraded, aggregating failures by field across many requests, or deciding whether a failure touched a field the caller actually needed. A client that groups its error metrics by `path` — with the integers stripped so `bins.4` and `bins.9` collapse together — gets a per-field failure rate almost for free. A client that groups by `message` gets a cardinality explosion the first time someone interpolates an id into the text.