How does a client reassemble a deferred GraphQL response from its incremental payloads?

## The client's job A client that supports incremental delivery is running a small merge loop, not a JSON parse. It reads payloads out of one streaming response body as they arrive, keeps a mutable response tree, and grafts each payload into that tree at the location the payload names. Three fields do all the work. **`path`** — an array of field names and integer list indices, counted from the root of `data`, exactly the same shape the specification already uses for error paths. `["account", "statements", 4]` means *the fifth element of the `statements` list on `account`*. The client walks that path in the tree it already holds and merges the payload's fields into the object it finds. If the payload arrives for a path whose parent is missing, the client has a bug or a malformed response — there is no ordering rule that lets a child arrive before its parent's container. **`label`** — the static string the client wrote in `@defer(label: "...")` or `@stream(label: "...")`, echoed back. `path` says *where*; `label` says *which deferred unit produced this*. That distinction matters when two deferred fragments hang off the same object: both payloads carry `path: ["account"]`, and only the label tells them apart. Drafts require the label to be a literal string, unique within the document, so a client can match it without evaluating variables. **`hasNext`** — a Boolean on every payload. `true` means more payloads are coming. `false` appears exactly once, on the last payload, and is the **only** completion signal. There is no trailing sentinel object, and the HTTP status is useless for this purpose because it was committed with the first bytes. ## Merging is additive A deferred fragment's fields are absent from the initial payload — not present-and-null. So a later payload never contradicts data the client already rendered; it fills a hole. This is why a naive merge is safe and why a UI can render the initial tree without defensive checks beyond "is this section here yet". Streamed list items behave the same way, with the index in the path doing the placing. Drafts differ on whether a streamed payload delivers one item or a batch of items appended at the tail of the list, which is another reason to hold the shape loosely and the invariants tightly. ## Framing The payloads travel as parts of one response body, conventionally `multipart/mixed` with a boundary, each part its own JSON document. The client must parse *incrementally* — a client that waits for the body to end before parsing has implemented incremental delivery and thrown away its only benefit. This is the single most common implementation mistake when a team hand-rolls the transport instead of using a client that already speaks it. ## Errors that arrive after the status A field error inside a deferred fragment produces an `errors` entry in the payload that carries it, with its own `path`. The response is already a 200, and it will stay a 200. Anything that decides success by status code — a retry wrapper, a dashboard, a synthetic check — will call a partially failed response healthy. That is a transport property of incremental delivery, not an error-handling nicety. ## Completion versus truncation Consider a statements screen with a deferred merchant-enrichment fragment inside each of twelve statement elements. Eleven payloads land. The twelfth never does, because the connection died mid-body — a laptop slept, a mobile network changed hands. What does the client have? A perfectly well-formed tree, eleven-twelfths filled, no error anywhere in it, a 200 status, and the last payload it read saying `hasNext: true`. Nothing distinguishes this from *still loading*, which is exactly why this failure presents as a screen that spins forever rather than as an error. The rule follows mechanically: **if the body ends and the last payload's `hasNext` was `true`, the response was truncated and must be treated as a failure.** A robust client also runs its own deadline for the remaining payloads and converts the timeout into a visible error state, or into a plain second operation that fetches the deferred fragment's fields on their own. ## The merge loop, stated plainly Start with `null`. First payload becomes the tree. Every later payload: walk its `path`, merge its `data`, collect its `errors`, and stop when `hasNext` is `false`. If the stream ends first, mark the tree truncated. That is the entire client contract, and being able to state it in five sentences is what the question is testing.