GET /api/events/:slug/attendees returns incorrect total in pagination — reports page size, not real count

[Srejoye]

Root cause: In apps/backend/src/routes/event.ts, the attendees endpoint fetches the event using a single findUnique with include: { attendees: { skip, take, ... } }. The skip and take clauses are applied to the nested attendees relation, so event.attendees only contains the records for the current page. Line 267 then computes total: event.attendees.length, which gives the count of records on that page (e.g. 10), not the count of all attendees in the database. A caller requesting page 2 gets total: 10 regardless of actual size, making any client-side pagination logic wrong.

Why it matters: Any frontend or mobile client using pagination.total to compute totalPages will show a wrong page count. On the last page with fewer results, total will be even smaller, making it impossible to build correct pagination UI. This is a quiet data correctness bug visible on every paginated attendees request with more than one page of results.

Affected files/functions: apps/backend/src/routes/event.ts, the GET /api/events/:slug/attendees handler, line 267.

Current behaviour: pagination.total equals event.attendees.length which is bounded by take (max 50). A 200-person event with limit=10 returns total: 10 on page 1, total: 10 on page 2, etc.

Expected behaviour: pagination.total should equal the real number of attendees for the event. If there are 200 attendees and you request page 2 with limit 10, total should be 200.

Minimal fix plan:
Replace the single findUnique with two queries run in parallel via Promise.all: (1) the existing paginated findUnique for the attendee page, and (2) a prisma.eventAttendee.count({ where: { eventId: event.id } }) for the real total. Use the count result in the pagination.total field. This requires a preliminary lookup of the event ID, which is already done anyway since the event is fetched first for the 404 check — use that event.id to run the count.

Suggested tests: Add a test in event.test.ts that mocks a full 25-attendee event, requests page 1 with limit 10, and asserts pagination.total === 25 (not 10). Also assert pagination.page === 1 and pagination.limit === 10.

[Srejoye]

Hi @Harxhit , @ShantKhatri & @PiyushRaval247 , I'd like to work on this under GSSoC'26.

I analyzed apps/backend/src/routes/event.ts in the GET /api/events/:slug/attendees handler.
The pagination total on line 267 is computed as event.attendees.length, but event.attendees is the already-paginated slice returned by Prisma's skip/take clauses on the nested include. So total is always at most limit (capped at 50), never the true attendee count. Any client computing total pages from this field will produce wrong results.

Proposed fix:

• Run a prisma.eventAttendee.count({ where: { eventId: event.id } }) in parallel with the page fetch
• Replace event.attendees.length with the actual count result in the response
• Add a test asserting pagination.total reflects the full attendee count across pages

This is a minimal safe change with no breaking behaviour. Please assign this issue to me. Thanks!

[Harxhit]

@Srejoye There is a better fix for that rather than using two queries just add _count to the same findUnique we already have in the attendees endpoint no two round trips one atomic query. Can you change the description by my suggestion or you can stay with yours upto you.