GraphQL returns RESOURCE_LIMITS_EXCEEDED when combining contributionsCollection and repositoriesContributedTo for a specific user

[plinkr]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

Hello,

I'm seeing a RESOURCE_LIMITS_EXCEEDED GraphQL error for my account (plinkr) when combining contributionsCollection with repositoriesContributedTo.

Each field works correctly when queried independently, but combining them in the same query consistently fails.

This behavior started recently without any changes to my application.

I can reproduce it directly using GitHub CLI, so this does not appear to be related to any third-party library.

---

Environment

gh version 2.88.1 (2026-03-12)
https://github.com/cli/cli/releases/tag/v2.88.1

Authenticated using a Personal Access Token.

---

Successful queries

contributionsCollection

query {
  user(login: "plinkr") {
    commits: contributionsCollection {
      totalCommitContributions
    }
  }
}

Response:

{
  "data": {
    "user": {
      "commits": {
        "totalCommitContributions": 148
      }
    }
  }
}

repositoriesContributedTo

query {
  user(login: "plinkr") {
    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

This also succeeds.

---

Failing query

query {
  user(login: "plinkr") {
    commits: contributionsCollection {
      totalCommitContributions
    }

    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

Response:

{
  "data": {
    "user": null
  },
  "errors": [
    {
      "type": "RESOURCE_LIMITS_EXCEEDED",
      "path": [
        "user",
        "repositoriesContributedTo"
      ],
      "locations": [
        {
          "line": 8,
          "column": 5
        }
      ],
      "message": "Resource limits for this query exceeded."
    }
  ]
}

---

Additional observations

The same happens when combining repositoriesContributedTo with another contributionsCollection field:

query {
  user(login: "plinkr") {
    reviews: contributionsCollection {
      totalPullRequestReviewContributions
    }

    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

This also returns RESOURCE_LIMITS_EXCEEDED.

Likewise, querying both contribution totals from a single contributionsCollection object still fails when repositoriesContributedTo is included:

query {
  user(login: "plinkr") {
    contributionsCollection {
      totalCommitContributions
      totalPullRequestReviewContributions
    }

    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

Response:

{
  "data": {
    "user": null
  },
  "errors": [
    {
      "type": "RESOURCE_LIMITS_EXCEEDED",
      "path": [
        "user",
        "contributionsCollection",
        "totalPullRequestReviewContributions"
      ],
      "locations": [
        {
          "line": 6,
          "column": 7
        }
      ],
      "message": "Resource limits for this query exceeded."
    }
  ]
}

---

Comparison

The same queries succeed for other users, for example:

• octocat
• torvalds

For example, the following query succeeds for torvalds:

query {
  user(login: "torvalds") {
    reviews: contributionsCollection {
      totalPullRequestReviewContributions
    }

    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

---

The rateLimit.cost is reported as 1, even for the failing query.
Could this be an account-specific issue affecting how contributionsCollection and repositoriesContributedTo are resolved together?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[hemkdev]

This looks like a resource-limit interaction between contributionsCollection and repositoriesContributedTo, not a bug in your app or gh itself.

contributionsCollection without an explicit from/to range scans your entire lifetime contribution history. When it's resolved in the same query as repositoriesContributedTo, the server has to cross-reference both at once — for an account with contributions spread across many repositories and years, that combined resolution can blow past GitHub's internal resource limit, even though rateLimit.cost still reports 1 (the rate-limit cost model doesn't reflect actual resolver/complexity cost).

octocat and torvalds likely succeed either because their contribution graph shape keeps the combined resolution cheaper, or because high-traffic accounts benefit from server-side caching that reduces the cost of resolving repositoriesContributedTo alongside contributionsCollection.

Workaround: scope contributionsCollection with an explicit from/to window (GitHub caps this at 1 year per call):

query {
  user(login: "plinkr") {
    contributionsCollection(from: "2025-01-01T00:00:00Z", to: "2025-12-31T23:59:59Z") {
      totalCommitContributions
      totalPullRequestReviewContributions
    }
    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

If you need full-lifetime totals, paginate year by year and sum the results client-side, rather than requesting the whole history combined with repositoriesContributedTo in a single query.

If that still throws RESOURCE_LIMITS_EXCEEDED even with a 1-year window, that would point more strongly to an account-specific server-side issue worth flagging to GitHub support directly, since it wouldn't be explained by query complexity anymore.

[Dhivakar2005]

Based on the information you've provided, this appears to be an internal GraphQL resolver limitation rather than an issue with your query or the GitHub CLI.

A useful diagnostic step would be to execute the same query while constraining contributionsCollection with a narrow from/to date range (for example, a single calendar year). If the query succeeds under those conditions, it would suggest that resolving the full contribution history alongside repositoriesContributedTo exceeds an internal resource threshold, even though the reported rateLimit.cost remains 1.

Conversely, if the query continues to return RESOURCE_LIMITS_EXCEEDED even with a minimal date range, that would strongly indicate an account-specific backend issue rather than query complexity. Given that:

• Each field executes successfully when queried independently.
• The combined query succeeds for other accounts (e.g., octocat and torvalds).
• The reported GraphQL cost remains unchanged.

there appears to be sufficient evidence to justify further investigation by the GitHub GraphQL team into the resolver behavior for this specific account.

[plinkr]

Thanks to the both of you for the detailed analysis, I ran the follow-up test you suggested (narrowing contributionsCollection to shorter from/to windows) and the results are as follow:

from	to	Span	Result
2025-01-01	2025-03-31	3 months	Success (53 PR review contributions)
2025-01-01	2025-04-30	4 months	Error RESOURCE_LIMITS_EXCEEDED
2025-02-01	2025-05-31	4 months	Success (65 PR review contributions)
2025-02-01	2025-06-30	5 months	Error RESOURCE_LIMITS_EXCEEDED
2025-02-01	2025-12-31	11 months	Error RESOURCE_LIMITS_EXCEEDED
2026-01-01	2026-12-31	12 months	Success (22 PR review contributions)
2024-01-01	2024-12-31	12 months	Error RESOURCE_LIMITS_EXCEEDED
2023-01-01	2023-12-31	12 months	Success (0 PR review contributions)
2022-01-01	2022-12-31	12 months	Success (0 PR review contributions)
2021-01-01	2021-12-31	12 months	Success (0 PR review contributions)
2020-01-01	2020-12-31	12 months	Success (0 PR review contributions)

In every failing case, the error path still points specifically at contributionsCollection.totalPullRequestReviewContributions

[hemkdev]

Thanks for running the tests — the table actually confirms the complexity hypothesis and narrows it down further:

• Every window with zero PR review contributions (2020–2023) succeeds.
• Failures only happen in windows containing substantial review activity (2024, the dense 2025 ranges), and the error path always lands on totalPullRequestReviewContributions.
• It's not the window length (a 3-month window fails while a 12-month one succeeds) — it's the cost of resolving the reviews inside that window combined with repositoriesContributedTo in the same request.

So the resolver cost scales with your review contribution graph (likely reviews in large/busy repositories are expensive to cross-reference), and the combined query trips GitHub's internal complexity limit — which rateLimit.cost: 1 doesn't reflect.

Definitive workaround: since each field works fine on its own (your original standalone lifetime query succeeded), just split them into two separate requests:

# request 1
query {
  user(login: "plinkr") {
    contributionsCollection {
      totalCommitContributions
      totalPullRequestReviewContributions
    }
  }
}

# request 2
query {
  user(login: "plinkr") {
    repositoriesContributedTo(first: 1) {
      totalCount
    }
  }
}

Two requests cost you nothing extra in rate limit terms (both are cost 1) and remove the failure mode entirely — no date-window guessing needed.

Beyond the workaround, your table is solid evidence for the GitHub team that the GraphQL cost model under-reports the real resolver cost of totalPullRequestReviewContributions — worth keeping this discussion open as feedback even after you unblock.