GraphQL currentUser.reviewRequestedMergeRequests times out when filtering by labelName

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

currentUser.reviewRequestedMergeRequests appears to time out very reliably when labelName is used, at least for the maintenance::dependency label. In my case this showed up while listing Renovate merge requests for review in a merge request tool, Zoolander (https://gitlab.com/andrewn/zoolander/), where the request nearly always time out even when only a small number of rows (5) were requested.

Note: the problem may be related to the number of projects containing a distinct copy of the "maintenance::dependency" label.

The workaround I implemented was to remove labelName from the GraphQL query and filter by label client-side instead. That change eliminated the timeout in practice.

Example query shape

A minimal reproduction looks like this:

query {
  currentUser {
    reviewRequestedMergeRequests(
      labelName: ["maintenance::dependency"]
      state: opened
      sort: UPDATED_DESC
      first: 20
    ) {
      pageInfo {
        hasNextPage
        endCursor
      }
      nodes {
        iid
        title
        webUrl
        project {
          fullPath
        }
        labels {
          nodes {
            title
          }
        }
      }
    }
  }
}

Steps to reproduce

  1. Run a GraphQL query against currentUser.reviewRequestedMergeRequests.
  2. Include labelName: ["maintenance::dependency"].
  3. Request a small page, for example first: 20.
  4. Observe that the query often times out after 15s with a 503.
  5. Remove labelName and retry the query.
  6. Optionally scope the query to a single project and filter labels client-side.
  7. Observe that the scoped/client-side-filtered approach returns quickly and avoids the timeout.

Current behaviour

The query times out when labelName is present. Reducing page size does not appear to address the underlying problem. In Zoolander this surfaced as a GraphQL timeout and led to the feature being reworked to avoid server-side label filtering entirely.

Expected behaviour

Filtering review-requested merge requests by labelName should be supported without routinely timing out, especially for modest page sizes.

Investigation notes

From debugging this in Zoolander, there seemed to be two separate contributors:

  • Query complexity in the all-projects path, where heavy per-merge-request fields were being fetched across currentUser.reviewRequestedMergeRequests for many projects at once.
  • A slow server-side label join triggered by labelName: "maintenance::dependency", which timed out regardless of page size.

Even after lightening the query, the workaround still needed to avoid labelName completely and apply label filtering in JavaScript/client-side.

Workaround

The current workaround is:

  • Drop labelName from the GraphQL query.
  • Fetch the results without server-side label filtering.
  • Filter for maintenance::dependency client-side.
  • If querying across many projects, compose the result per project rather than issuing one large cross-project query.

References

Possibly related

These are not exact duplicates, but they look directionally related:

  • gitlab-org/gitlab#592339 — group-level merge request GraphQL list timing out when filtering by author.
  • gitlab-org/gitlab#599354 — notes that merge request label filtering currently resolves label names via a DB query path that can cause timeouts and 500s.
Edited by 🤖 GitLab Bot 🤖