Bug: Facet loaders accept non-positive and unbounded pagination values

[pranjal2004838]

Summary

The facet route loaders currently accept any integer for page and page_size, including non-positive values (0, negative) and very large values, without bounds checks before server-side fetches.

Affected code

• src/routes/facets/[facet]/+page.ts
• src/routes/facets/[facet]/[value]/+page.ts
• src/lib/utils.ts (requireInt only checks parseability, not bounds)

Why this matters

• Non-positive values create invalid pagination behavior.
• Very large page_size can trigger oversized upstream requests and increase latency/memory usage.
• This is a server-side entry point, so malformed query params can be repeatedly abused.

Reproduction

1. Open a facet URL with invalid params, for example:
   • /facets/categories?page=0&page_size=0
   • /facets/categories?page=-5&page_size=100000
2. Observe that the loader accepts these values and forwards them to getFacet/getFacetValue.

Expected behavior

• Reject invalid values with 400 when:
  • page < 1
  • page_size < 1
• Enforce an upper bound for page_size (for example 100 or 200) and reject/clamp values above the cap.

Suggested fix

• Add a shared validator for positive bounded integers (or extend requireInt with min/max).
• Apply the same validation in both facet loaders to keep behavior consistent.

[pranjal2004838]

@VaiTon before we jump into fixing this, I want to make sure we're on the same page about how strict we should be:

First thing: When pagination values are dodgy (like page=0 or page_size=100000), should we:

Just reject them with a 400 error and tell users to fix their URL?
Or quietly fix them on our end (like page=0 becomes page=1)?

Secondly, Is there a "reasonable max" for page_size we should enforce? Like, should we cap it at 100, 200, or does the API already have a limit we should respect?

Thirdly I noticed /search has the same issue with pagination—no validation there either. Should we fix both while we're at it and maybe create a shared helper so this doesn't happen again?

And lastlyu: How should we talk to users if something goes wrong? Keep the error generic, or be more specific like "page_size needs to be at least 1"?

[harsh-791]

@VaiTon @pranjal2004838 just sharing my thoughts on the four questions, happy to be corrected:

Reject vs clamp — I'd lean toward clamping silently (page < 1 → 1, page_size above cap → cap value) so shared URLs don't break, and only reject with 400 when the value is genuinely unparseable. But open to whatever direction you prefer.

page_size cap — Maybe worth checking what the OFF API enforces upstream first, then picking something reasonable below that? 100 feels like a safe default but you'd know better.

Share the fix with /search — I think doing both in one PR with a shared helper (extending requireInt with min/max, or a new boundedInt) would keep things consistent.

Error messaging — If we clamp silently, no user-facing error is needed for out-of-range values. Just a simple "Invalid page parameter" for unparseable input.

@VaiTon does this approach sound right to you? If so, I'd love to help @pranjal2004838 on this issue — happy to pair up or take on part of the implementation.