Repository navigation
Feed: switch to cursor (keyset) pagination #22
Description
Part of #17 — Message composer & feed parity gaps
GET /api/messages exposes an opaque cursor for keyset pagination, with the explicit
instruction to "pass back the nextCursor from the previous response verbatim — never construct,
parse, or modify it."
MessagesApi.getMessages uses limit/offset, which drifts and duplicates rows as new posts
arrive at the head of the feed — exactly the case a social feed hits constantly.
- Move the feed (and search, if it supports it) to
cursor/nextCursor, keeping the cursor
opaque. :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 @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Activity
Adron commentedon Sep 16, 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.merge: #22 cursor pagination for the feed (PR #96)