Feature flag rollout - optimize_reset_approvals_preloading

Summary

This feature flag gates N+1 query optimizations in MergeRequestResetApprovalsWorker introduced in !224891 (merged).

The optimizations include:

  • Preloading :approvals and approval_rules: [:users, :group_users] in merge_requests_for_approval_reset
  • Eagerly loading approvals before rule evaluation
  • Preserving preloaded approval rules across cache resets

Feature issue: #579591

Owners

  • Team: Code Review
  • Most appropriate slack channel to reach out to: #g_code_review
  • Best individual to reach out to: @marc_shaw

Expectations

What are we expecting to happen?

Reduced database queries when processing code owner approval resets. The N+1 patterns that fire per code owner rule should be eliminated.

What might happen if this goes wrong?

The optimization should be safe — it only adds preloading and eager loading. If something goes wrong, the feature flag can be disabled to revert to the original query behavior.

What can we monitor to detect problems?

  • Error rates in Sidekiq for MergeRequestResetApprovalsWorker
  • Database query durations for approval reset operations

Rollout Steps

Rollout on non-production environments

  • Enable on staging: /chatops run feature set optimize_reset_approvals_preloading true --staging
  • Verify no errors in staging

Rollout on production

  • Enable for a specific project: /chatops run feature set --project=gitlab-org/gitlab optimize_reset_approvals_preloading true
  • Monitor for issues
  • Enable globally: /chatops run feature set optimize_reset_approvals_preloading true

Cleanup

  • Remove feature flag and cleanup code