Add rate limit for DELETE deployments endpoint
What does this MR do and why?
Add rate limit for DELETE deployments endpoint
Introduce a dedicated 500 req/min per-user rate limit for DELETE /api/v4/projects/:id/deployments/:deployment_id using Gitlab::ApplicationRateLimiter.
The endpoint previously had no specific limit, only inheriting the global Rack::Attack project ceiling of 2,000 req/min.
Register the key in ApplicationRateLimiter and the Labkit adapter, check it before processing the delete, and add a rate-limited endpoint spec covering per-user scope isolation.
References
https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/28426+
How to set up and validate locally
- Create a project with a couple of deployments (via the API or
in the Rails console). - (Optional, to avoid sending 500 requests) temporarily lower the
threshold in the Rails console:allow(Gitlab::ApplicationRateLimiter) .to receive(:threshold).with(:deployment_delete).and_return(2) or edit deployment_delete in lib/gitlab/application_rate_limiter.rb to a small value. - Delete deployments past the threshold as the same user:
curl --request DELETE \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "http://127.0.0.1:3000/api/v4/projects//deployments/<deployment_id>" - The first requests return 204 No Content; once the per-user
limit is exceeded the endpoint returns 429 Too Many Requests
with a Retry-After header. - Confirm a different user is not throttled (per-user scope).
- Run the spec:
bin/rspec spec/requests/api/deployments_spec.rb \
-e "rate limited endpoint"
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by Adebayo Adesanya