Cache committer emails from diff to cut query call rate
What does this MR do and why?
MergeRequest#committer_emails_from_diff backs the approval-committer filter (gated by approval_committer_emails_from_diff). It runs very frequently across the fleet and is one of the more expensive queries on the read replicas; SRE feedback on the rollout issue has repeatedly pointed at reducing its call rate.
The committer set of a merge request diff is immutable once the diff exists, so the result is safe to cache. This MR caches committer_emails_from_diff in Rails.cache keyed by the merge_request_diff id. A new push creates a new diff (and id), which naturally invalidates the entry; a six-hour TTL is only a backstop.
Gated behind a new gitlab_com_derisk feature flag so it can be rolled out and rolled back independently, given this query's incident history.
Feature flag
cache_committer_emails_from_diff(gitlab_com_derisk, default disabled)- Rollout issue: #590452
Testing
Specs cover both flag states:
- Enabled: result written to the cache keyed by the diff id, and subsequent calls are served from the cache without re-querying.
- Disabled: nothing written to the cache, and the query runs on every call.