# Replace `rate_limits` hash with static labkit Limiter objects Once the feature flags are removed (#28876) and the labkit path is the only path, the `rate_limits` hash in `ApplicationRateLimiter` becomes redundant. This issue replaces it with labkit `Limiter` objects as the single source of truth. Parent epic: https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/2021 Prerequisite: https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/28876 (feature flag cleanup) Related: https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/28853 (configuration evolution) ## Problem The Stage 2a adapter currently builds a new `Limiter` and `Rule` on every rate limit check, resolving `threshold(key)` and `interval(key)` from the `rate_limits` hash each time: ```ruby def run!(key, scope:) spec = SUPPORTED_RATE_LIMITS.fetch(key) rule = build_rule(key, spec) limiter = Labkit::RateLimit::Limiter.new(name: ..., rules: [rule]) result = limiter.check(identifier_for(rule, scope)) end def build_rule(key, spec) Labkit::RateLimit::Rule.new( limit: ApplicationRateLimiter.threshold(key), # resolves from hash period: ApplicationRateLimiter.interval(key), # resolves from hash ... ) end ``` The `rate_limits` hash is only used internally by `ApplicationRateLimiter` for: 1. **Validation** — `raise InvalidKeyError unless rate_limits[key]` 2. **Looking up threshold/interval** — `rate_limits[key][:threshold]` Callsites never access the hash directly. They only call `ApplicationRateLimiter.throttled?(:key, scope: ...)`. ## Proposed fix Replace both the `rate_limits` hash and `SUPPORTED_RATE_LIMITS` with a single `LIMITERS` hash that defines each rate limit as a labkit `Limiter` object. Each limit is defined manually — static values stay static, database-backed values use callables: ```ruby LIMITERS = { pipelines_create: Labkit::RateLimit::Limiter.new( name: "applimiter_pipelines_create", rules: [ Labkit::RateLimit::Rule.new( name: "limit_pipelines_by_project_user_sha", characteristics: %i[project_id user_id sha], limit: -> { ApplicationSetting.current.pipeline_limit_per_project_user_sha }, period: 1.minute, action: :block ) ] ), user_sign_in: Labkit::RateLimit::Limiter.new( name: "applimiter_user_sign_in", rules: [ Labkit::RateLimit::Rule.new( name: "limit_signins_by_user", characteristics: %i[user_id], limit: 5, period: 10.minutes, action: :block ) ] ), notes_create: Labkit::RateLimit::Limiter.new( name: "applimiter_notes_create", rules: [ Labkit::RateLimit::Rule.new( name: "limit_notes_by_user", characteristics: %i[user_id], limit: -> { ApplicationSetting.current.notes_create_limit }, period: 1.minute, action: :block ) ] ), # ... each of the ~100 rate limits defined explicitly }.freeze ``` Each entry carries everything: the limiter name, rule name, characteristics, limit (static integer or callable), period (static or callable), and action. No indirection through a separate hash, no `threshold(key)` / `interval(key)` lookup methods. `ApplicationRateLimiter.throttled?` becomes: ```ruby def throttled?(key, scope:, ...) limiter = LIMITERS.fetch(key) { raise InvalidKeyError, key } result = limiter.check(build_identifier(key, scope)) result.action == :block end ``` ## What gets removed - `rate_limits` hash (the ~100-entry frozen hash with Procs) - `SUPPORTED_RATE_LIMITS` hash (the adapter's per-key spec) - `threshold(key)` and `interval(key)` methods - `rate_limit_value(value)` and `rate_limit_value_by_key(key, setting)` - `build_rule` and per-request `Limiter.new` / `Rule.new` construction - The legacy `IncrementPerAction` / `IncrementPerActionedResource` / `IncrementResourceUsagePerAction` strategy classes (once all cohorts are migrated) ## What stays unchanged - `ApplicationRateLimiter.throttled?` public interface — callsites keep calling `.throttled?(:key, scope: ...)` - Admin API/UI — reads/writes `ApplicationSettings` directly, does not go through the `rate_limits` hash - Database-backed settings — callables on the labkit `Rule` resolve from `ApplicationSettings` at check time, same as the Procs in the current hash ## Benefits - No per-request object allocation for Limiter, Evaluator, or Rule - Evaluator is cached inside Limiter and reused across checks - Single source of truth for rate limit definitions (labkit rules) - Natural stepping stone to #28853 Phase 3 (static YAML config replaces the callables) ## Sequencing This must happen **after** the feature flag cleanup (#28876): 1. **#28876** — Remove feature flags, make labkit the only path. The `rate_limits` hash and legacy strategy classes are still present but only used by the labkit adapter indirectly. 2. **This issue** — Replace per-request construction with static Limiter objects, remove the `rate_limits` hash and legacy strategies. The labkit rule definitions become the source of truth. We should also feature flag this. These are separate MRs because: - Flag removal is mechanical and low-risk - Hash removal is a deeper refactor that changes the source of truth and needs careful validation ## Note on callables and future configuration The callables in the static `Rule` objects read from `ApplicationSettings`, preserving backwards compatibility for self-managed. When we move to static YAML-based configuration (#28853 Phase 3), the callables are replaced with static values loaded from config files. The static `Limiter` pattern established here carries over directly — only the rule source changes.