Problem
The GET /v1/deployments list endpoint has a default limit of 1000 with no upper bound enforced:
// deployment.schema.ts:138
limit: z.number().default(1000).optional()
Other list endpoints correctly enforce .max(100) (blocks, transactions, provider deployments, address endpoints). This endpoint is inconsistent and allows requesting arbitrarily large result sets.
Impact
A request with ?limit=999999 could:
- Cause expensive database queries
- Generate very large JSON responses that block the event loop during serialization
- Consume excessive memory for result buffering
Suggested Fix
Add .max() constraint consistent with other endpoints:
limit: z.number().default(100).max(100).optional()
If 1000 is needed for specific use cases, consider a separate internal endpoint or cursor-based pagination.
Files
apps/api/src/deployment/http-schemas/deployment.schema.ts (~line 138)
apps/api/src/deployment/routes/deployments/deployments.router.ts (~line 208)
Context
Part of the API event loop performance audit.
Problem
The
GET /v1/deploymentslist endpoint has a default limit of 1000 with no upper bound enforced:Other list endpoints correctly enforce
.max(100)(blocks, transactions, provider deployments, address endpoints). This endpoint is inconsistent and allows requesting arbitrarily large result sets.Impact
A request with
?limit=999999could:Suggested Fix
Add
.max()constraint consistent with other endpoints:If 1000 is needed for specific use cases, consider a separate internal endpoint or cursor-based pagination.
Files
apps/api/src/deployment/http-schemas/deployment.schema.ts(~line 138)apps/api/src/deployment/routes/deployments/deployments.router.ts(~line 208)Context
Part of the API event loop performance audit.