I build Pianory, a browser-based piano practice app. AI helped draft this article; I checked the claims against the course-ledger client, server handler and focused tests.
A course-attempt ledger can grow while a client is fetching more than one page. If every page treats the latest row as its endpoint, a new attempt can enter halfway through the pull. For this append-only feed, we keep two sequence values with different jobs: after marks progress, while through fixes the upper bound for one traversal.
The server selects rows with sequence > after and sequence <= through. It fetches one row beyond the requested page size to decide hasMore, then returns an advancing cursor. The client carries the same through value on later pages and rejects a changed upper bound or a page that does not advance.
The tests make the boundary concrete. In the client test, a sequence 104 is appended while the current traversal covers 1–103; the current pull ends at 103. In the server API test, five attempts added after the initial bound are excluded from that traversal, while a fresh traversal can see the later bound. pnpm exec vitest run src/lib/client/course-ledger.spec.ts src/lib/server/api/course-ledger.spec.ts passed 15 tests in two files on 1 November 2026.
This is a bounded design choice for Pianory's append-only course-attempt ledger, not a universal database snapshot guarantee. The focused client transport and server test harness verify these cases; they do not measure production sync latency or every deployment's concurrency behavior. Source: src/lib/client/course-ledger.ts, src/lib/server/api/course-ledger.ts, and their focused specs.
Top comments (0)