In a nested GraphQL connection, how does a client page one parent's children further?

## Every nested connection is a connection in its own right When a connection field is selected under a list of parents, the response contains one complete connection object per parent: its own `edges`, its own `pageInfo`, its own cursors. Those parts describe **that parent's** ordered child set and nothing else. In a freight-tracking graph, a board that pulls twenty-three shipments and the first ten scan events of each comes back with twenty-three `scanEvents` connections, and "show more scans for waybill AWB-8814" is a question about exactly one of them. ## Continuation is per parent, so the follow-up operation addresses one parent The natural instinct — re-run the outer page with a larger inner `first` — is wrong on three counts. It refetches twenty-two shipments nobody asked about. It refetches the ten scan events the client already has. And it is not a resume point: enlarging `first` re-slices from the beginning of that parent's ordering, so any row inserted since the first request shifts the window rather than appending to it. The correct shape is a second, much smaller operation that addresses that one shipment and continues its child connection with the cursor that connection itself produced: ```graphql query MoreScans($id: ID!, $after: String!) { shipment(id: $id) { scanEvents(first: 10, after: $after) { edges { cursor node { scannedAt facilityCode } } pageInfo { hasNextPage endCursor } } } } ``` How the client addresses a single parent is a separate matter — a domain root field taking the parent's key, or the generic refetch field the Relay server convention defines for globally identified objects. Either way the point stands: the unit of continuation is the parent, not the page. ## Cursors are scoped to the connection that produced them A cursor is an opaque token that means "this position in *this* ordered result set". Shipment AWB-8814's `endCursor` positions you inside AWB-8814's scan events. Handing it to shipment AWB-9207's `scanEvents(after:)` is not a smaller mistake than passing a random string; depending on how the server encodes cursors it will either error, return an empty page, or — worst — decode into a plausible sort key and return a page that looks fine and is silently wrong. Client state for nested lists therefore has to be keyed by parent: a map from parent identity to that list's cursor and exhaustion flag, never a single "next cursor" for the field. ## The outer pageInfo says nothing about the inner lists `shipments.pageInfo.hasNextPage` answers one question: are there more **shipments** after this page. It is not affected by, and tells you nothing about, whether any shipment has more scan events. Conversely a nested `hasNextPage: true` does not mean the outer page is incomplete. Two independent paging states exist at the two levels, and a UI that wires one "load more" button to both will either stall or double-fetch. ## What a correct implementation looks like on the client Three pieces of state per rendered parent: the items so far, that parent's `endCursor`, and that parent's `hasNextPage`. "Load more" on one card issues the single-parent operation above and appends. When the outer page itself advances, the newly arrived shipments come with their own first inner page and their own cursors; nothing about the already-loaded shipments' inner state changes. ## Why servers should keep the inner page small Because continuation is cheap and per parent, the inner default does not have to be generous. A first inner page of ten scan events per shipment, with a per-card continuation, costs far less than an inner page of a hundred that most cards never scroll — and the saving is multiplied by the outer page size. The asymmetry is the practical reason to treat the two levels' page sizes differently rather than reusing one number. ## The trap that survives review Two mistakes tend to pass code review because both produce plausible-looking data. The first is storing one cursor per *field* instead of one per parent, which only misbehaves once a user expands a second card. The second is deriving "there is more" from `edges.length === first` instead of reading that connection's `hasNextPage`; that heuristic is wrong exactly when the underlying page happened to be full, which is the common case, and it costs an extra empty round trip every time a child list ends on a page boundary.