Remove fix_minute_contention feature flag

Shabini Rajadasrequested to merge
589227-remove-fix-minute-contention-flag into master

What does this MR do and why?

Removes the fix_minute_contention feature flag and keeps the sharded write path it guarded.

Compute minute usage for a namespace is now always written to a shard of ci_namespace_monthly_usages derived from the build ID, rather than to a single row per namespace per month. Concurrent builds in the same namespace therefore spread their UPDATE across up to MAX_NUMBER_OF_SHARDS (10) rows instead of queueing on one, which is the write-lock contention this work set out to remove.

Changes:

  • Ci::Minutes::UpdateProjectAndNamespaceUsageService#namespace_usage calls find_or_create_current_shard unconditionally.
  • Deleted ee/config/feature_flags/gitlab_com_derisk/fix_minute_contention.yml.
  • Dropped a comment sentence on NamespaceMonthlyUsage.find_or_create_current that described what happened when the sharded write path was disabled. That state is no longer reachable.
  • Replaced the four flag-state contexts in the service spec with a single context covering the two behaviours that remain: the write lands on the build-derived shard, and writing to a non-first shard also creates shard 1.

NamespaceMonthlyUsage.find_or_create_current is deliberately kept. It is not dead code: Ci::Minutes::Usage#current_usage, Ci::Minutes::EmailNotificationService, and ee/spec/support/ci/minutes_helpers.rb still call it. Only the write path in the usage service was behind the flag.

No read path changes. Reads already aggregate across shards through all_current_usages, total_current_minutes_used, and aggregated_by_month, which shipped in the earlier MRs of this rollout.

No migration, no schema change, and no user-visible UI change.

References

Screenshots or screen recordings

Not applicable. No UI change.

How to set up and validate locally

Feature flags default to enabled in the test environment, so the sharded write was already the path under test before this MR. That means these specs confirm no regression; they do not by themselves prove the production default changed.

  1. Run the service spec:

    bin/rspec ee/spec/services/ci/minutes/update_project_and_namespace_usage_service_spec.rb

  2. Run the related compute minutes specs:

    bin/rspec ee/spec/models/ci/minutes/namespace_monthly_usage_spec.rb \
  ee/spec/models/ci/minutes/usage_spec.rb \
  ee/spec/services/ci/minutes/update_build_minutes_service_spec.rb \
  ee/spec/services/ci/minutes/email_notification_service_spec.rb

  3. To see the sharding directly, run a few builds in one namespace and check that more than one row exists for the current month:

    Ci::Minutes::NamespaceMonthlyUsage.current_month.for_namespace(namespace_id).pluck(:shard_number, :amount_used)
Ci::Minutes::NamespaceMonthlyUsage.total_current_minutes_used(namespace_id)

Local results: 16 examples 0 failures for the service spec, 276 examples 0 failures across the related specs, and RuboCop clean on the three changed files.

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.

Merge request reports