<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name[]=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name[]=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary The group-level merge request list on GitLab.com consistently times out when filtering by `Author`. The underlying GraphQL query (`getGroupMergeRequestsEE`) blocks for ~15 seconds and returns a timeout error, even though only 20 results are requested (`firstPageSize: 20`). The UI then shows "Too many results to display" with no actual results. This makes it impossible to use the merge request list UI to filter by author at the group level, which is critical for workflows that involve monitoring bot-authored MRs (e.g. Renovate). ### Steps to reproduce 1. Navigate to a group's Merge Requests page on GitLab.com (e.g. `https://gitlab.com/groups/thelabnyc/-/merge_requests`) 2. Add an `Author` filter (e.g. `Author = renovate-bot`, or any group bot user) 3. Observe the page loading indicator 4. After ~15 seconds, the GraphQL request fails and the UI shows **"Too many results to display — Edit your search or add a filter."** The issue reproduces regardless of which author is selected, but is easiest to trigger on groups with many projects and a high volume of merged/closed MRs (the `thelabnyc` group has 999+ merged and 197 closed MRs). It occurs on all MR states (Open, Merged, Closed, All). ### What is the current bug behavior? The POST to `https://gitlab.com/api/graphql` containing the `getGroupMergeRequestsEE` operation returns a timeout error after ~15 seconds: ```json { "errors": [ { "message": "Request timed out. Please try a less complex query or a smaller set of records." } ] } ``` The query variables include `"firstPageSize": 20` and `"authorUsername": "<username>"`, so this is not an unbounded request. The `sort` is `TITLE_ASC` and `state` is `opened`, both of which should be straightforward to index. The sort value doesn't not seem to have any effect, however, as this same bug happens for all sort options. The full GraphQL operation name is `getGroupMergeRequestsEE` and the relevant variable excerpt is: ```json { "fullPath": "thelabnyc", "sort": "TITLE_ASC", "state": "opened", "firstPageSize": 20, "authorUsername": "group_269576_bot_84b13d9f7a0398362d1300ecc7d551fc" } ``` The query requests `mergeRequests(... includeSubgroups: true ...)` which likely contributes to the timeout, as it must scan across all projects in the group hierarchy. ### What is the expected *correct* behavior? The group merge request list should return a paginated page of 20 results (or fewer) within a reasonable time frame when filtering by author, just as it does when no author filter is applied. The author filter should not cause the query to time out. ### Relevant logs and/or screenshots **Screenshot of the UI after timeout:** {width=900 height=489} **GraphQL error response** (from browser DevTools → Network tab): ```json { "errors": [ { "message": "Request timed out. Please try a less complex query or a smaller set of records." } ] } ``` **Request payload excerpt** (POST to `https://gitlab.com/api/graphql`): ```json { "operationName": "getGroupMergeRequestsEE", "variables": { "hideUsers": false, "isSignedIn": true, "fullPath": "thelabnyc", "sort": "TITLE_ASC", "state": "opened", "firstPageSize": 20, "afterCursor": null, "beforeCursor": null, "authorUsername": "group_269576_bot_84b13d9f7a0398362d1300ecc7d551fc" } } ``` ### Output of checks This bug happens on GitLab.com. **GitLab.com environment:** - Tested on: 2026-03-04 - Browser: Chrome (latest stable) - The group (`thelabnyc`) has multiple projects and subgroups - The group has 999+ merged MRs and 197 closed MRs - The author being filtered is a group bot user (Renovate Bot) - The bug occurs even when trying to view open MRs for the author and there are no open MRs (IOW the search times out even when it should return 0 results). ### Possible fixes The timeout likely stems from the combination of `authorUsername` + `includeSubgroups: true` producing a query plan that doesn't hit an efficient index path. Possible areas to investigate: - Ensure a composite index exists on `(author_id, state, ...)` for merge requests that supports the group-level subgroup-inclusive query - The query plan for group-level MR searches with author filter may be doing a sequential scan or an inefficient join across the `projects` → `namespaces` hierarchy