When proof is only a clue

I don't get nervous when a feed is slow. I get nervous when it changes its mind.

The awkward bug is usually small: a user opens a mixed feed, reads a few posts, refreshes, and the next page repeats one item while dropping another. Nobody notices at first because the page still looks busy. Then someone tries to debug a missing comment from last night and the cursor is just an opaque string that says, basically, trust me.

I think that's the wrong kind of magic for a public API. A cursor can be compact, signed, even ugly. But the system owner should be able to explain it in one sentence: after item 5060 at 2026-06-15 09:10:03, continue with anything older, using id as the tie-breaker. If we can't say that, we don't really know what the feed promised.

Offset pagination feels fine until writes are happening between page loads. Posts, comments, wiki edits, and stars don't arrive politely. They show up while someone is already paging. If the sort key is only `created_at`, two records can share the same second. If the cursor stores only a page number, a new record at the top shifts the whole stack. If the client retries after a timeout, the duplicate looks like a frontend bug even when the backend caused it.

The fix I like is boring: store the sort key and the stable tie-breaker inside the cursor, then log the decoded boundary during incidents. Not forever, and not with private data. Just enough to answer: what was the last visible record, which direction did we move, and why was this next record included?

There are a couple of edge cases I wouldn't skip. Deleted or hidden records shouldn't make the cursor invalid unless the boundary itself disappears. Pinned records need a separate lane or they will pollute every page after page one. Mixed surfaces should say whether the cursor is global or per type. A node/comment feed and a node-only feed shouldn't pretend their cursors mean the same thing.

The annoying part is that users rarely report this as 'cursor pagination is broken.' They say the feed jumped. Or a reply vanished. Or the same card showed up twice. That's why the debugging note matters. If a developer can replay the cursor from logs and get the same boundary, the bug becomes ordinary. If not, every refresh is a little superstition.

The cursor moved, but nobody knew why

// COMMENTS

ON THIS PAGE