Why can hasPreviousPage be false on a GraphQL connection page that has items before it?

## The rule, stated precisely The Relay server specification does not define the two page-info booleans symmetrically with respect to effort. Each has two branches, and only the first branch is an obligation. **`hasPreviousPage`** - If the client requested a **backward** slice: take the edges that remain after applying the client's cursors, and return true if there are more of them than the client asked for, false otherwise. This branch is exact. - Otherwise, if the client supplied an **after** cursor: the server may return true **if it can efficiently determine** that elements exist before that cursor. - Otherwise, false. **`hasNextPage`** is the mirror: exact when the client requested a forward slice, best-effort when the client supplied only a **before** cursor, false otherwise. The phrase that does all the work is "if the server can efficiently determine". It is permission, not obligation. A server that shrugs and returns false is compliant. ## Why the escape hatch exists The natural implementation of forward paging is a keyset read: everything ordered after the position the cursor names, bounded by the page size. That read knows a great deal about what comes *after* the cursor and nothing whatsoever about what comes before it. Answering `hasPreviousPage` honestly means a second read in the opposite direction — usually one row on the same index, and usually cheap. But not always: the source may be a remote service that only pages one way, an append-only log with no backward index, or a filter that is expensive to evaluate in either direction. The convention refuses to mandate work that some servers cannot do cheaply, so it makes the answer optional and pins the fallback to false. ## What that does to a client A museum collection graph pages a gallery's objects 24 at a time. The client is three pages in and asks for the next 24 objects after the cursor it holds; 48 objects precede this page. A fully compliant server may answer: ```json { "pageInfo": { "hasNextPage": true, "hasPreviousPage": false, "startCursor": "b3B1czoxNzcy", "endCursor": "b3B1czoxNzk1" } } ``` `hasPreviousPage: false` here is a shrug, not a fact. A user interface that hides its Previous control whenever that field is false will strand the reader on page three with no way back. The correct client rule is simple: **you know you have a previous page because you supplied a cursor to get here**, and because you kept the cursors of the pages you came from. On a forward-paged list, `hasPreviousPage` is at best a hint. ## The property worth memorising *The boolean in the direction you are travelling is the reliable one.* Page forward and `hasNextPage` is exact while `hasPreviousPage` is best-effort. Page backward and the roles swap: `hasPreviousPage` becomes exact and `hasNextPage` becomes the shrug. This is why `hasNextPage` feels trustworthy in practice and `hasPreviousPage` does not — it is not a difference between the fields, it is a difference in the direction almost every client happens to travel. ## The case where false is simply correct On the very first page — a forward request with no cursor at all — neither branch of the algorithm can produce true, so `hasPreviousPage` is false and that false is exactly right. Do not read laziness into it. The ambiguity only appears once a cursor is in play. ## If you want it to be truthful A server that wants to answer both booleans honestly on every page issues one extra bounded read in the opposite direction: does at least one element exist before this cursor, under the same filter and the same total order? On an indexed unique ordering this is a single-row lookup and costs almost nothing next to the page itself. Measure it before committing, because it is a per-page cost on every connection field in the schema, and if it is not cheap the convention's own answer is to return false rather than to pay. ## The interoperability trap Because truthful answers are permitted and false answers are compliant, two servers implementing the same convention can behave differently on identical requests. A client written against a generous server — one that always does the lookback — will quietly lose its Previous control when pointed at a compliant server that does not. If a platform team promises truthful booleans in both directions, that promise belongs in a written schema-design guideline, not in a client's assumptions. ## What an interviewer listens for Naming which branch of the algorithm a given request takes; saying "convention" rather than "the specification requires"; and finishing with what a client should do instead, rather than only diagnosing the server.