Add feature flag to gate default Sidekiq concurrency limit calculation

What does this MR do and why?

Adds a new sidekiq_concurrency_limit_default_calculation ops feature flag (disabled by default) that gates the percentage-based default concurrency limit calculation in calculate_default_limit_from_max_percentage.

In GitLab 18.9, GITLAB_SIDEKIQ_MAX_REPLICAS became set by default in the Helm charts (charts/gitlab!4348), which caused the concurrency limiter to activate on Self-Managed and Dedicated and the concurrency limiter was not tuned for these environments.

This feature flag ensures:

  1. Self-Managed and Dedicated installations are not affected by the default concurrency limit calculation unless explicitly opted in
  2. GitLab.com continues using the concurrency limiter as-is (flag enabled)
  3. Workers with an explicit concurrency_limit lambda are unaffected — only the default calculation is gated
  4. Gradual enablement on Dedicated once KEDA-based autoscaling is in place

References

How to set up and validate locally

  1. With the flag disabled (default), workers without an explicit concurrency_limit return 0 from get_concurrency_limit, even when GITLAB_SIDEKIQ_MAX_REPLICAS and SIDEKIQ_CONCURRENCY are set:
    Feature.disable(:sidekiq_concurrency_limit_default_calculation)
    stub_env("GITLAB_SIDEKIQ_MAX_REPLICAS", "10")
    stub_env("SIDEKIQ_CONCURRENCY", "10")
    SomeWorker.get_concurrency_limit # => 0
  2. With the flag enabled, existing behavior is preserved — default limits are calculated as ceil(percentage * max_replicas * concurrency):
    Feature.enable(:sidekiq_concurrency_limit_default_calculation)
    SomeWorker.get_concurrency_limit # => calculated value based on urgency

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 John Jarvis

Merge request reports

Loading