In a GraphQL error, what do the line and column values under locations point at?

middlenice to knowfreq 20%

answer

It points at text you sent
Beginning of a syntax element
Both numbers start at one
A list, because several places can apply

basics

~20 s

They point into the document text the client sent, marking the beginning of the relevant syntax element. Both numbers are positive integers starting at 1, and the entry is a list because one error can implicate several places.

solid answer

~50 s

locations describes a position in the document the caller sent — not the schema, not the response. Its value is a list of maps, each with line and column, both positive integers counting from 1, marking the beginning of the associated syntax element. It is a list because one error can legitimately involve more than one place in the document, such as a validation conflict between two selections. It is most useful for parse and validation failures, which happen while the document is still text. For a failure raised during execution it carries much less information: one field written once can fail thousands of times across a list, and every one of those errors reports the same locations, so only path tells them apart. It is also unusable at a distance: line 5, column 9 means nothing without the identical document in hand.

`locations` describes a position in the **document the caller sent** — not the schema, not the response. Its value is a list of maps, each with `line` and `column`, both **positive integers counting from 1**, marking the beginning of the associated syntax element. It is a list because one error can legitimately involve more than one place in the document, such as a validation conflict between two selections. It is most useful for parse and validation failures, which happen while the document is still text. For a failure raised during execution it carries much less information: one field written once can fail thousands of times across a list, and every one of those errors reports the same `locations`, so only `path` tells them apart. It is also unusable at a distance: line 5, column 9 means nothing without the identical document in hand.

code

graphql · 9 lines

graphql

query BinAudit {
  warehouse(id: "WH-7") {
    bins(zone: FROZEN) {
      stockItems {
        reorderPoint
      }
    }
  }
}

go deeper

for a junior

Know that locations refers to the query text you sent and that the numbers start at one. Seeing it in a syntax error and being able to jump to that spot in your editor is the whole everyday use.

for a middle

Explain that it marks the start of a syntax element, that both numbers are 1-based in contrast to path's 0-based indices, and that it is a list because one error can implicate several positions.

for a senior

Show judgement about when it is worthless: minified or generated documents, callers sending an identifier instead of text, and execution errors where one written field yields many identical locations. Steer diagnostics towards path and codes.

for a principal

Decide what your organisation actually retains. Storing full document text to make locations meaningful has cost and privacy implications; a document identifier plus path and code is usually the cheaper, safer contract.

What locations actually points at

locations is the optional entry in a GraphQL error that says where in the text the caller sent the problem lives. Its value is a list of maps; each map holds exactly two keys, line and column, and both are positive integers starting at 1, marking the beginning of the associated syntax element.

Three things are worth fixing in memory. It refers to the executable document the client sent — not the schema, not the response, not a server source file. Its numbers are 1-based, in contrast to the 0-based list indices used by the path entry of the same error. And it is a list, not a single position.

Why a list

Because one error can genuinely implicate more than one place in a document. The classic case is a validation failure about a conflict: two selections in the same set that cannot be merged, or two definitions sharing a name. Reporting one of the two positions and hiding the other would make the error much harder to act on, so the format allows every relevant position to be listed.

Where it comes from

The server has just parsed the document into a syntax tree, and every node in that tree remembers where it started in the source text. When an error is attached to a node, the position comes along for free. That is also why locations is the entry you reliably get for parse and validation failures — those happen while the document is still very much a piece of text — and why it is comparatively uninteresting for a failure raised inside a resolver, where the interesting question is not "where was this written" but "which value in the response is missing".

The example

graphql

query BinAudit {
  warehouse(id: "WH-7") {
    bins(zone: FROZEN) {
      stockItems {
        reorderPoint
      }
    }
  }
}

An error naming reorderPoint reports { "line": 5, "column": 9 } — line five of the text as sent, column nine, where the field name begins. Reformat the document, or send it minified onto one line, and those numbers change completely while the operation is byte-for-byte equivalent in meaning.

Why it is often useless in production, and what to reach for instead

That last sentence is the whole reason this is worth an interview question rather than a footnote.

You need the exact text to make sense of it. Line 5 column 9 means nothing to whoever reads the log unless the identical document text is in front of them, whitespace included. A client that builds its document by string concatenation, a build step that minifies it, or a caller that sends a hash of a document registered elsewhere rather than the text itself — in each case the coordinates survive the trip and their frame of reference does not.

It is a compile-time coordinate, not a runtime one. A document may mention a field once and the response may contain it three thousand times, once per element of a list. All three thousand failures report the same locations. Only path distinguishes them. So for anything that happened during execution, path is the entry that carries information and locations is nearly constant.

It is optional. The specification says an error should carry it when the error can be associated with a point in the document. A client must therefore handle its absence, and cannot make it a required part of any error-handling contract.

The practical rule that follows: use locations while you are holding the document — writing it, debugging it in an editor, reading a syntax error from a request you just made by hand. Use path and a code in extensions for everything a program or an operator does at a distance.

The 1-versus-0 trap

Both numbers in a locations map start at 1, because they describe a position in text the way an editor's status bar does. The integers in the same error's path start at 0, because they index into JSON lists the way every programming language does. Being asked to state both, in one breath, and getting one of them backwards is a common way to lose a small mark on an otherwise good answer.

Is any of this the interviewer's real target?

Usually not — which is what makes it a differentiator rather than a gate. Nobody's offer turns on knowing that columns start at 1. But a candidate who can say why locations exists, why it is a list, and why they would not build alerting on it has demonstrated they have actually read the error format rather than pattern-matched it from a screenshot.

## What locations actually points at `locations` is the optional entry in a GraphQL error that says **where in the text the caller sent** the problem lives. Its value is a list of maps; each map holds exactly two keys, `line` and `column`, and both are **positive integers starting at 1**, marking the **beginning of the associated syntax element**. Three things are worth fixing in memory. It refers to the **executable document the client sent** — not the schema, not the response, not a server source file. Its numbers are **1-based**, in contrast to the 0-based list indices used by the `path` entry of the same error. And it is a **list**, not a single position. ## Why a list Because one error can genuinely implicate more than one place in a document. The classic case is a validation failure about a conflict: two selections in the same set that cannot be merged, or two definitions sharing a name. Reporting one of the two positions and hiding the other would make the error much harder to act on, so the format allows every relevant position to be listed. ## Where it comes from The server has just parsed the document into a syntax tree, and every node in that tree remembers where it started in the source text. When an error is attached to a node, the position comes along for free. That is also why `locations` is the entry you reliably get for parse and validation failures — those happen while the document is still very much a piece of text — and why it is comparatively uninteresting for a failure raised inside a resolver, where the interesting question is not "where was this written" but "which value in the response is missing". ## The example ```graphql query BinAudit { warehouse(id: "WH-7") { bins(zone: FROZEN) { stockItems { reorderPoint } } } } ``` An error naming `reorderPoint` reports `{ "line": 5, "column": 9 }` — line five of the text as sent, column nine, where the field name begins. Reformat the document, or send it minified onto one line, and those numbers change completely while the operation is byte-for-byte equivalent in meaning. ## Why it is often useless in production, and what to reach for instead That last sentence is the whole reason this is worth an interview question rather than a footnote. **You need the exact text to make sense of it.** Line 5 column 9 means nothing to whoever reads the log unless the identical document text is in front of them, whitespace included. A client that builds its document by string concatenation, a build step that minifies it, or a caller that sends a hash of a document registered elsewhere rather than the text itself — in each case the coordinates survive the trip and their frame of reference does not. **It is a compile-time coordinate, not a runtime one.** A document may mention a field once and the response may contain it three thousand times, once per element of a list. All three thousand failures report the same `locations`. Only `path` distinguishes them. So for anything that happened during execution, `path` is the entry that carries information and `locations` is nearly constant. **It is optional.** The specification says an error *should* carry it when the error can be associated with a point in the document. A client must therefore handle its absence, and cannot make it a required part of any error-handling contract. The practical rule that follows: use `locations` while you are holding the document — writing it, debugging it in an editor, reading a syntax error from a request you just made by hand. Use `path` and a code in `extensions` for everything a program or an operator does at a distance. ## The 1-versus-0 trap Both numbers in a `locations` map start at 1, because they describe a position in text the way an editor's status bar does. The integers in the same error's `path` start at 0, because they index into JSON lists the way every programming language does. Being asked to state both, in one breath, and getting one of them backwards is a common way to lose a small mark on an otherwise good answer. ## Is any of this the interviewer's real target? Usually not — which is what makes it a differentiator rather than a gate. Nobody's offer turns on knowing that columns start at 1. But a candidate who can say *why* `locations` exists, why it is a list, and why they would not build alerting on it has demonstrated they have actually read the error format rather than pattern-matched it from a screenshot.

Why would you not build production alerting on the locations entry?
Because it is a coordinate into text you may not have. A minified document, one assembled by string concatenation, or a caller that sends a registered document's identifier rather than its text all leave the numbers meaningless to whoever reads the log. It is also nearly constant for execution failures, since one written field can fail many times. Alert on a code in `extensions` and group by `path`.
If both locations and path are present, which tells you more about a runtime failure?
`path`. It names the exact position in the response that failed, including list indices, so a thousand failures from one written field are a thousand distinguishable paths but a single shared location. `locations` only tells you where the field was written, which you usually already know. The reverse holds before execution: a syntax or validation error has no `path`, and `locations` is the only positional information available.

saying these in an interview costs you the question

Saying locations points into the schema definition
Assuming line and column are 0-based
Expecting a single location object rather than a list
Treating locations as identifying which response value failed
Believing every error must carry locations

In a GraphQL error, what do the line and column values under locations point at?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What locations actually points at

Why a list

Where it comes from

The example

Why it is often useless in production, and what to reach for instead

The 1-versus-0 trap

Is any of this the interviewer's real target?

▾common follow-ups2 questions

▾red flags5 flags

§ context

▾related questions4 questions

▾related topics3 topics

What locations actually points at

Why a list

Where it comes from

The example

Why it is often useless in production, and what to reach for instead

The 1-versus-0 trap

Is any of this the interviewer's real target?

answer

go deeper

context