A GraphQL connection is sorted only by a non-unique timestamp. What breaks when a client pages through rows that tie on it?

## The setup A clinic's appointment connection is ordered by `scheduledAt` ascending. A client walks it with `first: 50, after: <cursor>`. Server-side, the cursor is decoded back into the ordering values it carries and turned into a fetch that says, in effect, "rows that sort after this one". If the only ordering value is a timestamp, and timestamps repeat, that fetch cannot be written correctly. There are two candidate predicates and both are defective. ## Predicate A: strictly greater — the client silently loses rows ``` where scheduledAt > cursor.scheduledAt order by scheduledAt asc limit 50 ``` Suppose the last row of the previous page had `scheduledAt = 2026-03-02T09:00:00Z`, and 8,400 rows share that exact value because a migration stamped a whole recall batch with one timestamp. The previous page delivered 50 of them. This predicate now excludes *every* row at that timestamp — including the 8,350 not yet delivered. The client jumps straight to 09:05 and never learns that 8,350 appointments exist. Nothing errors; the page is well-formed and `hasNextPage` is honest about the rows the predicate can still see. ## Predicate B: greater-or-equal — the list grows without a bound ``` where scheduledAt >= cursor.scheduledAt order by scheduledAt asc limit 50 ``` Now the tied block is never excluded. Every request re-selects rows from the same 8,400 and the storage layer, having no further ordering instruction, is free to return them in a different arrangement each time. `hasNextPage` remains true forever, the client keeps asking, and the accumulated result list grows without a bound — the same appointment id appearing dozens of times — until the process runs out of heap or an operator kills it. This is the classic production incident behind this question: an unbounded paging loop that is actually a tie-defect, not a client bug. ## Why "just order by scheduledAt" is not enough even without the predicate problem Even ignoring the resume predicate, the arrangement *within* the tied block is not defined. Two executions of the same fetch can return the 8,400 rows in different sequences — different plans, a parallel scan, a different replica, a different cache state. So even a server that somehow tracked an offset into the block would be indexing into a sequence that is not the same sequence next time. ## The fix: compare the pair, not the key Make the order total by appending a unique, immutable column — the row id — and resume with a **lexicographic** comparison over the pair: ``` where scheduledAt > cursor.scheduledAt or (scheduledAt = cursor.scheduledAt and id > cursor.id) order by scheduledAt asc, id asc limit 50 ``` Read it as: strictly later timestamps always qualify; at the *same* timestamp, only rows whose id sorts after the cursor's id qualify. That predicate has exactly one correct answer for every row, so the 8,400 tied rows are traversed in a fixed internal sequence, 50 at a time, each row exactly once, and the walk terminates. The cursor therefore has to carry both ordering values, not just the visible sort key — the server cannot reconstruct the second half of the comparison from a timestamp alone. Note also that the comparison direction has to track the sort direction: for a descending sort both halves become `<`, including the tie-breaker half. Mixing them (descending timestamp, ascending id) is a real and easy bug, and it produces exactly the same duplicate-and-skip symptoms inside every tied block. ## Detecting it The symptoms are recognisable and worth being able to name in an interview: - **Duplicate ids across pages.** Collect ids while walking and assert the set size equals the row count. Repeats mean predicate B. - **A page walk that never ends,** or that returns far more rows than the collection contains. - **Missing rows that reappear when the page size changes.** With predicate A, whether a row is skipped depends on where the page boundary happens to land inside the tied block, so changing `first` from 50 to 100 changes which rows vanish. Anything whose correctness depends on page size is a tie defect. - **A defect that only shows up in production.** Test fixtures usually have distinct timestamps; bulk imports, batch jobs, coarse date-only sources and low-resolution clocks are what create large tied blocks. ## Client-side workarounds, and why they are not the fix Deduplicating by id on the client hides predicate B's repeats but not predicate A's omissions, and it does nothing about the unbounded loop — the backend is still being asked for pages forever. Capping the number of pages a client will fetch is a sensible seatbelt, not a fix. The defect is in the ordering, so the fix belongs in the ordering: every sort the field supports ends with a unique column, and every resume comparison is lexicographic over the whole tuple.