feat(core): paginate progress run listings - #2531
2 potential issues found
Code Review Summary
PR #2531 adds optional keyset pagination to progress-run listings, exposes the cursor through the existing read-only HTTP route, makes ordering deterministic with (started_at DESC, id DESC), and adds a supporting index plus focused tests. The cursor predicate and owner/active filtering are otherwise consistent with the intended page-boundary semantics, and the existing array response shape is preserved. This is a standard-risk core/API change.
Key Findings
- 🟡 MEDIUM — The new composite index is only ordering-compatible when
statusis constrained; default unfiltered listings cannot use it to efficiently produce the requested order. - 🟡 MEDIUM —
Date.parse()accepts some malformed calendar dates by normalizing them, so invalid cursors can be silently treated as different valid timestamps instead of returning HTTP 400.
The route/store validation split is a good defensive boundary, and the added tests cover complete cursor forwarding, incomplete cursor rejection, SQL predicate construction, and invalid timestamp rejection. The cursor behavior should be tightened and the unfiltered traversal index addressed before relying on this for large run histories.
🧪 Browser testing: Skipped — PR only modifies core store/route logic, types, tests, and a changeset; there is no user-facing UI impact.