.github/instructions/performance-review.instructions.md states the rule without an exception:
Every list endpoint has a server-enforced limit, including operator endpoints.
GET /api/v1/provider-credentials and GET /api/v1/search-tools both select every row and return all of them. Neither takes a limit, and neither repository applies one, so the read is unbounded in the database as well as on the wire.
The practical risk is low today: both tables are operator-authored and small. The point is that nothing keeps them that way, and the guideline says operator endpoints are in scope.
Why this is filed rather than fixed in #1211
CodeRabbit raised the same gap against the new guardrail_credentials store on #1211, and that one was fixed there: repositories/guardrail_credentials_repository.py now carries a MAX_GUARDRAIL_CREDENTIALS ceiling that list_guardrail_credentials applies in SQL. The two older stores are the pattern #1211 was modeled on, so bounding them is the same change in two more places and belongs in its own PR rather than widening a feature branch.
Review thread: #1211 (comment)
Scope
- A ceiling in
provider_credentials and search_tool_credentials list reads, applied in SQL.
- Same shape as the guardrail one: a module constant plus a keyword-only
limit, no new query parameter, so no OpenAPI, Postman or web/src/client/schema.ts regeneration.
- If a query parameter is wanted instead, all three stores should gain it together and the four generated artifacts regenerate in that PR.
.github/instructions/performance-review.instructions.mdstates the rule without an exception:GET /api/v1/provider-credentialsandGET /api/v1/search-toolsboth select every row and return all of them. Neither takes alimit, and neither repository applies one, so the read is unbounded in the database as well as on the wire.The practical risk is low today: both tables are operator-authored and small. The point is that nothing keeps them that way, and the guideline says operator endpoints are in scope.
Why this is filed rather than fixed in #1211
CodeRabbit raised the same gap against the new
guardrail_credentialsstore on #1211, and that one was fixed there:repositories/guardrail_credentials_repository.pynow carries aMAX_GUARDRAIL_CREDENTIALSceiling thatlist_guardrail_credentialsapplies in SQL. The two older stores are the pattern #1211 was modeled on, so bounding them is the same change in two more places and belongs in its own PR rather than widening a feature branch.Review thread: #1211 (comment)
Scope
provider_credentialsandsearch_tool_credentialslist reads, applied in SQL.limit, no new query parameter, so no OpenAPI, Postman orweb/src/client/schema.tsregeneration.