fix(users): cap huge follow-list offsets before Supabase range queries

[Nexu0ps]

Fixes #356

Caps offset at 100_000 for GET /api/users/[username]/followers and GET /api/users/[username]/following before building the Supabase .range() call, matching the pagination-hardening pattern used across other public endpoints.

[greptile-apps]

Greptile Summary

Caps the offset query parameter at 100_000 on the GET /api/users/[username]/followers and GET /api/users/[username]/following endpoints, preventing unbounded Supabase .range() calls that could degrade database performance.

• Both route files receive an identical one-line change wrapping parseNonNegativeInt(...) with Math.min(..., 100_000), matching the cap already in place on the activity endpoint.
• The existing test suites cover invalid params and large limits but do not include a case asserting that an offset above 100_000 is clamped — worth adding to lock in the new behaviour.
• A shared parsePaginationParam utility in @/lib/api-pagination already supports an upper bound argument and could consolidate this logic in a future cleanup.

Confidence Score: 4/5

Safe to merge — both changes are a single-line guard that can only make the offset smaller, with no effect on valid queries.

The two changed lines are straightforward and do exactly what the PR description says. The only gaps are style-level: the test suites don't assert on the new cap, and the inline helper duplicates logic that a shared utility already handles elsewhere.

The companion test files (followers/route.test.ts and following/route.test.ts) are missing a case for large-offset capping introduced by this change.

Important Files Changed

Filename	Overview
src/app/api/users/[username]/followers/route.ts	Adds Math.min(..., 100_000) guard on offset before the Supabase range call; functionally correct and matches the pattern used on other endpoints.
src/app/api/users/[username]/following/route.ts	Identical one-line change to cap offset at 100_000; same logic and same considerations as the followers route.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Route as followers / following route
    participant Supabase

    Client->>Route: "GET ?offset=<any value>"
    Note over Route: parseNonNegativeInt(offset, 0)
    Note over Route: Math.min(parsed, 100_000) new cap
    Route->>Supabase: profiles.select().eq(username).single()
    Supabase-->>Route: targetProfile
    Route->>Supabase: follows.select().range(offset, offset+limit-1)
    Note over Supabase: offset is now <= 100_000
    Supabase-->>Route: rows + count
    Route-->>Client: "{ data, pagination: { offset (capped), limit, total } }"

Loading

_{Reviews (1): Last reviewed commit: "fix(users): cap follow-list offset at 10..." | Re-trigger Greptile}

[greptile-apps]

Inconsistent pagination helper vs. sibling endpoints

The activity route uses a shared parsePaginationParam utility from @/lib/api-pagination which already accepts a max argument (e.g. parsePaginationParam(searchParams.get("offset"), 0, 0, 100_000)). This file (and following/route.ts) duplicates parsePositiveInt / parseNonNegativeInt locally and wraps them with an inline Math.min. Using the shared helper would keep the offset-cap boundary in one place and reduce the surface for future drift.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!