[FF] rate_limiter_resolve_limits_from_registry -- resolve rate limit values from the labkit registry

Summary

Roll out the feature currently behind the rate_limiter_resolve_limits_from_registry feature flag.

  • DRI: @mwoolf
  • Team Slack channel: #proj-ai-to-prod-rate-limits

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?

The flag switches where ApplicationRateLimiter.threshold/interval read each rate limit's value from: the legacy rate_limits hash (flag off) or the labkit SupportedRateLimits registry (flag on), introduced in !240022 (merged). The dispatch path is identical either way; only the value source changes.

  • A mistranscribed limit/period in the registry would change a key's effective threshold. A parity spec compares both sources for every key on every CI run, so this would require a value that drifts between deploys.
  • If a registry entry somehow lacked a value: a nil limit resolves to 0, which disables that limiter (fail-open, no user impact); a nil period raises InvalidKeyError at the call site. The registry-coverage guard spec makes both unreachable for registered keys.
  • Rollback is instant and safe: both sources share the same labkit Redis counters, so toggling the flag mid-window neither resets nor double-counts anything.

Watch the 429 rate and the gitlab_rate_limiter metrics on the rate-limiting dashboards (dashboards.gitlab.net) — the signal of a wrong value is a per-key step change in throttle rate.

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_limiter_resolve_limits_from_registry 50 --actors --dev --pre --staging --staging-ref
/chatops gitlab run feature set rate_limiter_resolve_limits_from_registry true --dev --pre --staging --staging-ref

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

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

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. The follow-up MR that removes this flag also deletes the legacy rate_limits hash, threshold/interval resolution from it, and the Increment* strategy classes (tracked in the work item).

/chatops gitlab run release check https://gitlab.com/gitlab-org/gitlab/-/merge_requests/240022 19.2
/chatops gitlab run feature delete rate_limiter_resolve_limits_from_registry --dev --pre --staging --staging-ref --production

Rollback

/chatops gitlab run feature set rate_limiter_resolve_limits_from_registry false                                         # production
/chatops gitlab run feature set rate_limiter_resolve_limits_from_registry false --dev --pre --staging --staging-ref     # non-production
/chatops gitlab run feature delete rate_limiter_resolve_limits_from_registry --dev --pre --staging --staging-ref --production  # remove entirely

🤖beep boop

Edited by 🤖 GitLab Bot 🤖