fix(http): reject negative limit/offset on list endpoints with 422 instead of raw Postgres 500#2357
Merged
nicoloboschi merged 2 commits intoJun 23, 2026
Conversation
…stead of 500 Several user-facing GET list endpoints declared limit/offset without ge constraints, so a negative value flowed straight into Postgres LIMIT/OFFSET (emitted with no max(0, ...) clamp), which raises 'LIMIT/OFFSET must not be negative'. The generic `except Exception -> HTTPException(500, str(e))` then turned a client input error into a 500 that also leaked the raw Postgres error string. Add Query(ge=...) constraints (limit ge=0, offset ge=0) on the affected endpoints (graph, memories/list, documents, tags, entities, entities/graph), matching the ge constraints already enforced on the sibling list endpoints (document-chunks, directives, async-ops, audit) so FastAPI returns a clean 422 at the boundary. ge=0 rejects only negatives and preserves limit=0 (a valid empty page), so there is no behavior change for any previously-valid request.
…aints Adds minimum:0 to limit/offset params across openapi.json, docs-skill spec, Go openapi.yaml, and Python clients; lint reformats the new test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several user-facing GET list endpoints declared
limit/offsetwithout FastAPIgeconstraints, so a negative value flows straight into PostgresLIMIT/OFFSET(the engine emitsLIMIT $n OFFSET $nwith nomax(0, ...)clamp), which raisesLIMIT/OFFSET must not be negative. The genericexcept Exception -> HTTPException(500, str(e))then turns a client input error into a 500 that also leaks the raw Postgres error string.Affected endpoints (all verified against
memory_engine.pySQL):GET …/graph,…/memories/list,…/documents,…/tags,…/entities,…/entities/graph.The same router already enforces this on sibling list endpoints —
document-chunks,directives,async-ops,auditall useQuery(..., ge=…). This makes the missing ones consistent.Fix: add
Query(ge=0)to thelimit/offsetparams.ge=0rejects only negatives, solimit=0(a valid empty page,LIMIT 0) andoffset=0still work — no behavior change for any previously-valid input, only the negative inputs that were always broken now get a clean 422 instead of a 500.Test:
test_list_endpoint_pagination_validation.pyasserts negativelimit→ 422 across all six endpoints, negativeoffset→ 422 where applicable, and a positive control thatlimit∈ {0, 1, 100} is still accepted.