GraphQL query complexity limit exceeded when agent attempted to fetch all review threads

TL;DR: The query is rejected because nested page sizes multiply - asking for 100 threads with 100 comments each looks like 10,000 nodes to the complexity scorer. Shrink the page sizes, split the query into smaller ones (threads first, then comments per thread), and drop fields you do not need. Small cheap queries that paginate always beat one giant query.

GraphQL query complexity limit exceeded when agent attempted to fetch all review threads

1. Read the rejected query and find the nested pagination. Look for a pattern like threads(first: 100) containing comments(first: 100) - the product of the two is what the scorer counts. Expected: you can point at the exact nested fields driving the score over the limit.

2. Cut the outer page size first. Drop threads to a small batch (for example 20 per request) and paginate with the end cursor. Expected: the query score falls roughly in proportion to the page-size cut.

3. Split nested fetching apart. Fetch the thread list first, then fetch comments per thread in separate small queries instead of nesting them. Expected: each query scores low on its own; the total work is the same but spread across cheap requests.

4. Trim the field selection. Remove every field the review does not use - full bodies you never read, nested author details, reaction lists. Expected: a further score drop, since selected fields count toward complexity too.

5. Re-run the batched fetch and walk every cursor to the end. Expected: all threads and comments retrieved with no complexity errors.

6. Verify completeness: count the threads fetched against the PR's review-thread total. Expected: the counts match, confirming pagination did not drop anything.

Use this when

• A review-threads query is rejected for exceeding complexity limits
• The agent tries to fetch all threads and comments in one GraphQL call
• Nested first: N arguments multiply into a huge implied node count
• You need a reliable pattern for deep PR data via GraphQL

Not for this skill when

• The failure is a REST API rate limit (different mechanism, different fix)
• The query fails with a syntax or validation error rather than a complexity error
• The data you need is available from a REST endpoint (use it instead of fighting GraphQL)
• The limit hits on a query with no nesting (then the query itself is just too broad - narrow the scope)

Variant phrasings

• "GitHub GraphQL complexity limit on PR review threads"
• "query too complex fetching pull request comments"
• "reduce GraphQL query cost for review threads"
• "paginate review threads to avoid complexity error"

Why it happens

GitHub scores a query's cost before running it, and nested connections multiply: 100 threads times 100 comments reads as 10,000 potential nodes plus the cost of every selected field. The scorer does not know most threads have few comments - it prices the worst case. Pagination keeps the worst case small per request, which is exactly what the scorer rewards.

Edge cases

• Resolved threads still count when fetched. Filter them out in a first pass if the review only needs open threads.
• Cursors expire on very long fetch sessions. If a cursor goes stale, restart that batch from the last good page.
• Batching multiplies request count, which spends the REST-style rate budget faster. Watch the rate-limit headers alongside complexity.
• Some fields (like suggested-change diffs) are disproportionately expensive. Fetch those only for the threads that need them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4zT1HixS868WlWsBAUlVQ