Description
Add bounded pagination and deterministic ordering to collection endpoints that return group expenses or settlement records. This prevents large groups from causing slow responses and gives clients a stable way to load older activity without missing or duplicating records between requests.
Context & Requirements
The API is a Fastify and TypeScript backend using Prisma, and every request must be validated with Zod. Collection responses are consumed by the web client through types in mergepay-web/src/lib/types.ts. Use a consistent cursor or page-based contract based on the repository's existing route conventions; do not introduce several incompatible pagination styles in one change. Sort by a unique, immutable tie-breaker such as creation time plus ID, and cap the requested page size server-side.
Pagination must remain scoped to the authenticated user's permitted groups. Do not let a cursor bypass membership or admin checks, and do not use an unbounded database query before slicing the result.
Acceptance Criteria
Implementation Guidance
Locate the collection routes and Prisma queries under src, then compare their response types with mergepay-web/src/lib/types.ts. Follow current Zod schemas and Fastify error responses. Prefer database-level ordering and cursor filtering over in-memory slicing, and ensure the cursor encodes enough information to prevent ambiguous timestamp-only ordering.
Testing & Validation
Add route and query tests covering first, middle, and final pages; equal timestamps; invalid and oversized parameters; empty results; and unauthorized group access. Verify that the generated query does not fetch the full collection. Run npm run build, npm test, and npm run lint, and update API contract documentation or client types as required.
Submission Guidelines
Assignment is required before starting. Open one PR that includes Closes #<issue-number>, keeps one consistent pagination contract across the touched endpoints, and follows repository naming and response conventions.
Wave complexity: Medium
Description
Add bounded pagination and deterministic ordering to collection endpoints that return group expenses or settlement records. This prevents large groups from causing slow responses and gives clients a stable way to load older activity without missing or duplicating records between requests.
Context & Requirements
The API is a Fastify and TypeScript backend using Prisma, and every request must be validated with Zod. Collection responses are consumed by the web client through types in
mergepay-web/src/lib/types.ts. Use a consistent cursor or page-based contract based on the repository's existing route conventions; do not introduce several incompatible pagination styles in one change. Sort by a unique, immutable tie-breaker such as creation time plus ID, and cap the requested page size server-side.Pagination must remain scoped to the authenticated user's permitted groups. Do not let a cursor bypass membership or admin checks, and do not use an unbounded database query before slicing the result.
Acceptance Criteria
Implementation Guidance
Locate the collection routes and Prisma queries under
src, then compare their response types withmergepay-web/src/lib/types.ts. Follow current Zod schemas and Fastify error responses. Prefer database-level ordering and cursor filtering over in-memory slicing, and ensure the cursor encodes enough information to prevent ambiguous timestamp-only ordering.Testing & Validation
Add route and query tests covering first, middle, and final pages; equal timestamps; invalid and oversized parameters; empty results; and unauthorized group access. Verify that the generated query does not fetch the full collection. Run
npm run build,npm test, andnpm run lint, and update API contract documentation or client types as required.Submission Guidelines
Assignment is required before starting. Open one PR that includes
Closes #<issue-number>, keeps one consistent pagination contract across the touched endpoints, and follows repository naming and response conventions.Wave complexity: Medium