[FF] rate_limiting_rule_bypass_header -- Bypass-header traffic visibility in ApplicationRateLimiter

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Roll out the feature currently behind the rate_limiting_rule_bypass_header feature flag.

This change makes bypass-traffic volume visible for the first time by routing requests with the trusted infra bypass header through labkit's rate-limiter (where they hit a :skip rule that never blocks them, but increments a Prometheus counter). The flag exists so the team can enable it deliberately during working hours and observe the metric appear in real time, rather than behavior changing silently on deploy.

  • DRI: @hardikgala
  • Team Slack channel: #g_tenant-controls

Note

Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. Feature flag controls · Feature flag lifecycle

What could go wrong?

  • Bypass-header requests now flow through labkit's key-registration and settings-lookup checks instead of short-circuiting before them. If those checks raise exceptions, bypass traffic will no longer be immune. This tradeoff was reviewed with the rate-limiting maintainer and accepted, since those checks validate the rate limiter's own configuration: a property shared by all requests to the endpoint, not unique to bypass traffic.
  • No expected Redis or performance impact: :skip rules never write to Redis by design.

Rollout

Run all production /chatops in #production and cross-post the results to #proj-ai-to-prod-rate-limits. Background: incremental rollout process, feature actors.

Non-production

/chatops gitlab run feature set rate_limiting_rule_bypass_header 50 --actors --dev --pre --staging --staging-ref


/chatops gitlab run feature set rate_limiting_rule_bypass_header true --dev --pre --staging --staging-ref

Production (percentage rollout, wait ≥15 min between steps, watch dashboards):

/chatops gitlab run feature set rate_limiting_rule_bypass_header <percentage> --actors

Or target specific actors instead:

/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss rate_limiting_rule_bypass_header true


/chatops gitlab run feature set --group=gitlab-org,gitlab-com rate_limiting_rule_bypass_header true


/chatops gitlab run feature set --user=hardikgala rate_limiting_rule_bypass_header true

Before global rollout

Confirm the relevant gotchas before going to 100%, see enabling a feature for GitLab.com:

Cleanup

Remove the flag once deemed stable, see cleaning up. Track it here, or open a follow-up Feature Flag Cleanup issue. Remove the flag and its YAML definition from the codebase, then:

/chatops gitlab run release check <merge-request-url> <milestone>


/chatops gitlab run feature delete rate_limiting_rule_bypass_header --dev --pre --staging --staging-ref --production

Rollback

/chatops gitlab run feature set rate_limiting_rule_bypass_header false                                         # production


/chatops gitlab run feature set rate_limiting_rule_bypass_header false --dev --pre --staging --staging-ref     # non-production


/chatops gitlab run feature delete rate_limiting_rule_bypass_header --dev --pre --staging --staging-ref --production  # remove entirely
Edited by 🤖 GitLab Bot 🤖