Reset ci_lint_limit_per_user to unlimited

What does this MR do and why?

Reset ci_lint_limit_per_user to unlimited

The CI Lint rate limit has never been enforced. Since 19.2 it has sat behind the ci_enforce_ci_lint_rate_limit flag, which only logs the requests that exceed the limit.

We are now getting ready to enforce it. Whatever value an instance holds today has never blocked anything, and on most instances it is there only because 19.2 seeded it from pipeline_limit_per_user. Enabling the flag against those values would start rejecting requests against a limit nobody deliberately chose.

Reset the setting to 0 everywhere first, so enforcement begins from no limit and administrators pick one once the feature is announced.

Regular migration rather than post-deployment, so there is no deploy window where the enforcing code runs before the reset.

Changelog: changed

References

Relates to https://gitlab.com/gitlab-org/gitlab/-/work_items/599486

Database

This is a data migration. It changes no schema: only the ci_lint_limit_per_user key in the rate_limits JSONB column of application_settings, on rows where it currently holds a non-zero value. No rows are deleted.

UPDATE application_settings
SET rate_limits = jsonb_set(rate_limits, '{ci_lint_limit_per_user}', '0')
WHERE COALESCE((rate_limits->>'ci_lint_limit_per_user')::int, 0) != 0

Sequential scan, which is expected: no index serves a predicate on a key inside a JSONB column, and
application_settings is table_size: small.

down is a deliberate no-op. The previous values are not recorded anywhere, so there is nothing to
restore them from, and re-seeding from pipeline_limit_per_user would put back exactly the limits
this migration exists to clear. To recover, an administrator re-enters a value in the Admin Area,
under Settings > Network > Pipeline creation rate limits.

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.

Related to #599486

Edited by Tarun Raja

Merge request reports

Loading
Loading