Add pagination and sorting to GET /v1/communities/:communityId/members

[Lakes41]

Difficulty: Intermediate
Type: feature

Background
The admin member-listing endpoint GET /v1/communities/:communityId/members is one of the four MVP endpoints documented in the README, intended for admin use.

Problem
As currently documented, the endpoint returns member listings with no visible pagination or sort parameters, which will not scale for communities with many members and risks large, slow responses.

Expected outcome
The endpoint accepts page/pageSize (or cursor-based cursor/limit) query params plus a sort param (e.g., joinedAt, role), returns a paginated envelope (data, total, nextCursor), and the OpenAPI spec is regenerated to reflect the new params.

Suggested implementation

• Update the Fastify route schema in apps/access-api for this endpoint to accept pagination/sort query params with Zod/JSON-schema validation.
• Update the Prisma query to use skip/take or cursor-based pagination against the members/memberships tables.
• Add a paginated response type to packages/shared-types.
• Run npm run -w access-api openapi:generate and commit the updated docs/openapi.json.
• Add/extend packages/sdk-lite to pass through the new params.

Acceptance criteria

• Endpoint supports pagination and returns total count
• Default page size is reasonable (e.g., 25) and capped (e.g., max 100)
• docs/openapi.json reflects the new query params
• sdk-lite exposes the new params in its client method
• Existing tests updated, new tests added for pagination boundaries

Likely affected files/directories

• apps/access-api/src/routes/ (community members route)
• packages/shared-types/
• packages/sdk-lite/
• docs/openapi.json

[DiegoMoron0102]

Hi, I've reviewed the issue and would like to take this on.I've worked on Fastify/Zod route schemas with Prisma pagination before, so I know what shape the Fastify/Zod validation expects here. Plan is offset pagination (page/pageSize) rather than cursor: the envelope asks for total, and offset gives that honestly in one query path — I'd still keep nextCursor in the response type so switching to cursors later isn't a breaking change for sdk-lite. Default 25, hard cap 100, rejected with a 400 rather than silently clamped. sort on joinedAt or role, always with id as tiebreaker, since role isn't unique and ordering would otherwise drift between pages. The paginated type lands in packages/shared-types first, so the route, the regenerated docs/openapi.json and sdk-lite all derive from one source instead of three hand-written copies. I'm realistic that total is a second count query and gets expensive on large communities; I'd rather keep it and document the cost than return a number that isn't real. Tests would cover page 0, over-cap pageSize, the empty tail page, and stable ordering across page boundaries. Happy to pick this up whenever you're ready to assign it.

[grantfox-oss]

🦊 GrantFox — @DiegoMoron0102 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #259)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@DiegoMoron0102's PR #315 was approved and merged by @Lakes41.

🏆 @DiegoMoron0102: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (83 total points). Track your full progress on GrantFox.

👏 Great work, @DiegoMoron0102! Keep contributing to Adamantine-guild.