feat(api): separate rate limit budget for deployment endpoints - #4565
Conversation
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe PR adds shared matching rules for deployment API endpoints and tests positive and negative path cases. It adds a Redis-backed deployment rate limiter with environment-configured token budgets, logging, caching, and private API-key scoping. The server loads and orders the limiter after the general API limiter. The change exports the limiter and documents its environment variables and separate budget. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches 💡 1📝 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 |
myftija
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
1c91608 to
f71b500
Compare
Most deploy-flow API calls (build-time env var resolution and sync, env key exchange, preview branches) drew from the same general API rate limit bucket as an environment's runtime traffic, so a busy environment could starve its own deployments; the /api/v*/deployments endpoints themselves were fully exempt from rate limits as a stopgap. The whole group now goes through a dedicated limiter with its own token bucket, keyed per environment for environment API keys and per token for PATs/OATs, configurable via DEPLOYMENT_RATE_LIMIT_* env vars. The general API limiter whitelists the group via a shared path list. /api/v1/deployments/current is runtime SDK surface and stays exempt from rate limits as before, outside the deploy budget.
f71b500 to
189a3b3
Compare
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
2 participants
Most deploy-flow API calls shared the general per-environment rate limit bucket with all of that environment's runtime traffic, so an org with heavy API usage could intermittently 429 its own deploys; the
/api/v*/deploymentsendpoints themselves were fully exempt from rate limits as a stopgap (#2774), which promised a dedicated limiter as the follow-up. This is that follow-up: the whole deploy-flow group now runs on its own budget, separate from runtime API limits.Design
A new
deploymentRateLimitercovers every endpoint the deploy flow depends on: the/api/v*/deploymentsgroup, the env API key exchange (/api/v1/projects/:ref/:env), build-time env var resolution and sync (/envvars,/envvars/:slug/import), preview branches,/api/v1/remote-build-provider-statusand/api/v1/artifacts. The general API limiter whitelists the same shared path list, so exactly one limiter applies to each path and the two can't drift apart.Buckets are keyed per environment for environment API keys and per token for the PAT-authenticated phase of a CLI deploy (whoami, key exchange, branches). The deploy budget is controlled via the
DEPLOYMENT_RATE_LIMIT_*env vars.