GraphQL operation approvalSummary can be too slow for Rails in large MRs

Summary

Similarly to Investigate slowness in getState GraphQL query (#562586 - closed), I think there can also be a performance bottleneck with approvalSummary.

This also seems related to #463017 (comment 1933159594)

Steps to reproduce

  1. Check .com logs: json.graphql.operation_name: "approvalSummary" and json.meta.caller_id: "GraphqlController#execute" and json.cpu_s > 50 (internal dashboard)
  2. Search for a found example with json.correlation_id: "…" and use the json.variables field to construct the MR URL.
  3. Check the MR, and confirm number of commits, changes, and note that the Approval widget does not load.
  4. Check number of CODEOWNERS in the project (incl. size of aliased groups). The line count in CODEOWNERS is not the crucial factor, I think.

Example Project

See steps above to find them. Also, in this internal customer case, a CODEOWNERS file with >5k and MRs that change thousands of files ran into the gitlab_rails['graphql_timeout']/global.appConfig.graphQlTimeout limit.

I also started reproducing this internally, but maybe the lack of real usernames (I didn't want to risk pinging anyone) prevented triggering the problem. Or, the test MRs were still too small.

What is the current bug behavior?

Approval widget does not load and back-end logs 500/Rack::Timeout::RequestTimeoutException.

What is the expected correct behavior?

A clearer error (maybe based on documented limit to the number of commits, changes or CODEOWNER rules that are parsed) or improved performance for even such large MRs.

Relevant logs and/or screenshots

See steps above to find them.

Output of checks: This bug happens on GitLab.com

Possible fixes

See expected behaviour ideas above.

Edited by Katrin Leinweber