Repository navigation
Feed: switch to cursor (keyset) pagination #22
Description
Activity
- added a parent issue
on Sep 15, 2026 Implemented in #96 (branch
issue/22-cursor-pagination). Closing here — review and any follow-up happens on the PR.Worth recording: the live spec declares no
offsetparameter at all onGET /api/messages— onlylimit,onlyMine,tagandcursor. So the old paging was sending a parameter the server does not document. A confirmed live response returnspagination: { total, offset, limit, hasMore, nextCursor }withnextCursoras an opaque base64 keyset token.Search was deliberately left on its current paging:
GET /api/messages/searchaccepts onlyq,limitandonlyMine— there is no cursor to hand back.- added a commit that references this issue
on Sep 16, 2026
Part of #17 — Message composer & feed parity gaps
GET /api/messagesexposes an opaquecursorfor keyset pagination, with the explicitinstruction to "pass back the
nextCursorfrom the previous response verbatim — never construct,parse, or modify it."
MessagesApi.getMessagesuseslimit/offset, which drifts and duplicates rows as new postsarrive at the head of the feed — exactly the case a social feed hits constantly.
cursor/nextCursor, keeping the cursoropaque.
:feature:directmessagesalready does this correctly — mirror that implementation.Tests: repository paging test that a new head insert does not duplicate or skip rows.
Filed from the parity review of
feature/parity-wip@14d7795against interlinedlist.com (OpenAPI/api/openapi.json, 233 paths) and the public help centre.