fix(queries): clamp agent and candidate page values

[Jorel97]

Summary

• clamp agent and candidate query helper pages before deriving Supabase ranges
• fall back to page 1 for non-numeric page values
• add regression coverage for negative, non-numeric, and huge page values in both helper tests

Fixes #334.

Verification

• Added focused Vitest coverage in agents.test.ts and candidates.test.ts.
• Not run locally: this Codex workspace has Node but no npm/package runner available, so I could not execute the Vitest files here.

[greptile-apps]

Greptile Summary

This PR fixes unbounded page values in the buildAgentsQuery and buildCandidatesQuery helpers by introducing a parsePage function that clamps input to [1, 100_000] and falls back to 1 for non-numeric strings, preventing negative offsets or runaway Supabase range values.

• agents.ts and candidates.ts: replace the bare parseInt(page || "1") call with a new parsePage helper guarded by Number.isFinite and Math.min/Math.max clamping.
• agents.test.ts and candidates.test.ts: add three regression tests each covering negative, non-numeric, and very large page values.

Confidence Score: 4/5

Safe to merge — the clamping logic is correct and the new tests validate all the edge cases the fix targets.

The parsePage helper is implemented correctly and consistently across both query files. The only concern is that the helper is duplicated rather than shared, which could cause the two files to drift if the clamping logic is ever revisited.

Both agents.ts and candidates.ts carry identical copies of parsePage and MAX_PAGE; consider extracting to a shared utility to avoid future drift.

Important Files Changed

Filename	Overview
src/lib/queries/agents.ts	Adds parsePage helper that clamps page to [1, 100_000] and falls back to 1 for NaN; identical copy exists in candidates.ts
src/lib/queries/candidates.ts	Mirrors agents.ts — same parsePage helper and MAX_PAGE constant duplicated verbatim
src/lib/queries/agents.test.ts	Adds three regression tests covering negative, non-numeric, and huge page values; expectations match implementation behaviour
src/lib/queries/candidates.test.ts	Same three regression tests as agents.test.ts, mirrored for the candidates query helper

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["parsePage(value?)"] --> B{"value falsy?"}
    B -- yes --> C["use '1'"]
    B -- no --> D["parseInt(value, 10)"]
    C --> D
    D --> E{"Number.isFinite?"}
    E -- no (NaN) --> F["return 1"]
    E -- yes --> G["Math.max(parsed, 1)"]
    G --> H["Math.min(result, 100_000)"]
    H --> I["return pageNum"]
    I --> J["offset = (pageNum - 1) × 20"]
    J --> K["query.range(offset, offset + 19)"]

Loading

_{Reviews (1): Last reviewed commit: "test(queries): cover invalid page ranges" | Re-trigger Greptile}

[greptile-apps]

Duplicated parsePage helper

parsePage is now defined identically in both agents.ts and candidates.ts. If the clamping logic ever needs to change (e.g. a different MAX_PAGE, or switching from parseInt to Number), it will need to be updated in both places. Extracting it to a shared utility (e.g. src/lib/queries/utils.ts) would eliminate this drift risk.

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!