fix(users): default malformed search limits

[Jorel97]

Fixes #344.

This keeps /api/users/search from passing NaN into supabase.limit(...) when callers send malformed limit values. Valid numeric limits still clamp to 1..20, and malformed values now fall back to the default limit of 10.

I also added regression coverage for limit=abc.

Verification: local dependency install is unavailable in this workspace, so I validated the targeted source/test changes and will follow the PR checks.

[greptile-apps]

Greptile Summary

Fixes a bug in /api/users/search where malformed limit query parameters (e.g. limit=abc) produced NaN from parseInt and passed it directly to supabase.limit(...). The guard is replaced with a Number.isFinite check that falls back to 10 for non-finite values, while valid integers are clamped to the [1, 20] range.

• route.ts: Replaces the limitParam || 10 falsy-OR pattern with Number.isFinite(parsedLimit) ? clamp(...) : 10, correctly handling NaN and also changing the limit=0 behaviour from silently defaulting to 10 to correctly clamping to 1.
• route.test.ts: Adds a test for the reported limit=abc case plus an it.each block covering 0 → 1, -1 → 1, and Infinity → 10, addressing the edge-case gaps noted in the previous review round.

Confidence Score: 5/5

The change is safe to merge; it narrows a well-scoped input-parsing bug with no risk of regression.

The fix is minimal and self-contained: two lines in route.ts replace a fragile falsy-OR guard with an explicit Number.isFinite check, and the new tests cover every affected branch. No other call sites or data paths are touched.

No files require special attention.

Important Files Changed

Filename	Overview
src/app/api/users/search/route.ts	Replaces the falsy-OR guard with a Number.isFinite check so NaN from parseInt never reaches supabase.limit(); also correctly changes limit=0 to clamp to 1.
src/app/api/users/search/route.test.ts	Adds a dedicated test for limit=abc (the reported bug) plus an it.each block covering limit=0, limit=-1, and limit=Infinity, closing the gaps flagged in the previous review thread.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["GET /api/users/search?q=...&limit=..."] --> B{Auth check}
    B -- "not authenticated" --> C["401 Unauthorized"]
    B -- "authenticated" --> D["parseInt(limitParam || '10', 10)"]
    D --> E{Number.isFinite?}
    E -- "false (NaN e.g. 'abc', 'Infinity')" --> F["limit = 10 (default)"]
    E -- "true (valid integer)" --> G["Math.min(Math.max(1, parsed), 20)"]
    G --> H["limit ∈ [1, 20]"]
    F --> I{Empty query?}
    H --> I
    I -- "yes" --> J["200 { users: [] }"]
    I -- "no" --> K["supabase.from('profiles').select(...).ilike(...).limit(limit)"]
    K --> L{error?}
    L -- "yes" --> M["500 Failed to search users"]
    L -- "no" --> N["200 { users: [...] }"]

Loading

_{Reviews (2): Last reviewed commit: "test(users): cover search limit edges" | Re-trigger Greptile}

[greptile-apps]

Silent behavior change for limit=0

The old code used limitParam || 10, which treated 0 as falsy and silently defaulted to 10. The new code uses Number.isFinite(0) === true, so limit=0 now flows through the clamp and becomes 1. This is arguably the more correct outcome, but it's an undocumented behavior change and there's no test asserting it. Worth adding a test case for limit=0 → expects mockLimit called with 1 so the intent is explicit and won't regress silently.

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!

[Jorel97]

Added a follow-up test commit for the Greptile edge-case note. The test suite now covers malformed limit values plus 0, negative, and Infinity cases; route logic is unchanged from the original fix.