perf(webapp): clamp list-endpoint page size to 100#4360
Conversation
|
WalkthroughList pagination handling was updated across admin, API, and resource routes. Requested page sizes are validated as positive values where applicable and capped at 100. Existing defaults remain for routes that define them, and the LLM model loader now also enforces a minimum page size. A change notice documents the capped list endpoint behavior. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Several list endpoints accepted an unbounded page size. Clamp perPage / per_page / pageSize to 100 on the schedules, queues, versions, engine-report, and llm-models endpoints, matching the existing cap on the runs and sessions endpoints. Oversized requests now return up to 100 items and keep paginating instead of pulling an unbounded page.
350c680 to
55f68d2
Compare
2 participants
Summary
Several list endpoints accepted an unbounded page size (
perPage/per_page/pageSize). An unbounded page lets one request pull an arbitrarily large result set and do a proportional amount of work, which is a poor default for a shared API.This clamps the page size to 100 on every list endpoint that was uncapped, matching the existing cap on
api.v1.runsandapi.v1.sessions. Clamping rather than rejecting keeps existing clients working: a request for a larger page returns up to 100 items and offset pagination continues from there.Endpoints capped
api.v1.schedules(perPage)api.v1.queues(perPage)resources.…versions(per_page)resources.…queues(per_page)admin.api.v1.…engine.report(per_page)admin.api.v1.llm-models(pageSize)Already capped, left as-is:
api.v1.runs,api.v1.sessions,api.v1.deployments.