Merge request list times out when filtering by Author (GraphQL getGroupMergeRequestsEE)

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:

{
    "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:

{
    "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:

Too many results to display

GraphQL error response (from browser DevTools → Network tab):

{
    "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):

{
    "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
Edited by 🤖 GitLab Bot 🤖