Repository navigation
fix(api): query pagination accepts non-integer limit/page → fractional OFFSET/LIMIT #785
Description
Describe the bug
POST /v1/query DynamicQueryRequest accepts non-integer limit/page without validation and produces fractional LIMIT/OFFSET that fail ClickHouse Int32 binding.
Affected code:
apps/api/src/schemas/query-schemas.ts:49-50DynamicQueryRequestSchema: t.Optional(t.Number())— nominimum/integerconstraint.apps/api/src/routes/query.ts:294-308validatePaginationFieldsonly checks<1and>10000/<1forpage, notNumber.isInteger/isFinite.apps/api/src/routes/query.ts:1040-1041limit: request.limit || 100,offset: request.page ? (request.page-1)*(request.limit||100) :0→ withlimit=1.5, page=1.5yieldsoffset=0.75(fractional).packages/ai/src/query/simple-builder.ts:1148-1154buildLimitClause/buildOffsetClauseemitLIMIT 1.5 OFFSET 0.75vs. buildersLIMIT {limit:Int32} OFFSET {offset:Int32}(packages/ai/src/query/builders/pages.ts:182,sessions.ts:318, etc.).- Internal
packages/ai/src/query/index.ts:61-62QuerySchema: z.number().min(1).max(1000)also allows floats (missing.int()).
To Reproduce
- Authenticated request:
POST /v1/query?website_id=<id>&timezone=UTC
Content-Type: application/json
{
"parameters": ["top_pages"],
"startDate": "2026-01-01",
"endDate": "2026-01-02",
"limit": 1.5,
"page": 1.5
}
- Also try
{"limit": 0.5},{"page": 1.5},{"limit": 1.5, "page": 2.3}.
Expected behavior
400 VALIDATION_ERROR with details like:
{ "field":"limit", "message":"Limit must be an integer" }
{ "field":"page", "message":"Page must be an integer" }limit/page should require finite integer, limit 1..10000, page 1...
Actual behavior
No validation error; request reaches ClickHouse with fractional values. Reproduced locally with copy of validatePaginationFields (D:\tmp\repro_pagination.js):
float limit {limit:1.5} => errors=[] limit=1.5 offset=0 BUG non-integer passed
float page {page:1.5} => errors=[] limit=100 offset=50 BUG
both float => offset 0.75 BUG not integer
Infinity/NaN similarly slip through (JSON NaN not encodable but Elysia coercion from query string can produce floats).
buildLimitClause(NaN) → '' (unbounded), buildLimitClause(0) → ''.
Screenshots
N/A
Environment
- OS: Windows, Bun 1.4.2 (
package.json:30bun@1.4.1pinned) - Commit:
92c15273d(origin/staging)
Additional context
limitdefault fallback|| 100masks0/NaNinapps/api/src/routes/query.ts:1040,simple-builder.ts:1149fallback similarly.limitmax mismatch: API allows10000(validatePaginationFields:301), internalQuerySchemaallows1000— not part of this bug but worth aligning.- No existing open issue covers this (checked
gh issue list). - Minimal fix proposal: tighten
DynamicQueryRequestSchema(TypeBoxminimum), addNumber.isInteger/isFiniteinvalidatePaginationFields, add.int()toQuerySchema(packages/ai/src/query/index.ts:61-62), add regression test.
AI disclosure
Issue drafted with assistance from Muse Spark (opencode/muse-spark-1.2-contributor-free) and human-verified via local reproduction (node D:\tmp\repro_pagination.js).
Activity
Devesh36 commentedon Sep 21, 2026
Hi, I reproduced this against the current staging branch and traced the validation path through DynamicQueryRequestSchema, validatePaginationFields, and the internal query schema.
I’d like to take a small PR that adds finite-integer validation at the API boundary plus focused regression tests. I’ll keep the change limited to pagination validation and won’t address the separate 1,000/10,000 limit mismatch unless requested.
Is this issue accepted for an external contribution, and is that scope aligned with what you want?