GraphQL: Could not resolve to a PullRequest with the number of"

TL;DR

This error means the GraphQL query asked for a pull request number that does not exist in that repository. Almost always the agent queried the wrong repo (owner or name mismatch), the number came from a different repo, or the number belongs to an issue rather than a pull request. Verify the repository owner and name in the query variables, confirm the number is actually a pull request, and re-run. It is a targeting error, not an auth error.

The query

"GraphQL: Could not resolve to a PullRequest with the number of"

Use this when

• A review bot or agent gets this exact error from GitHub's GraphQL API.
• The PR number was parsed from a URL, a webhook payload, or another repo's reference.
• The same query works for some PRs but fails for others.

Not for

• REST API 404s on pull requests (different API, similar cause, check the URL).
• 403 or "Resource not accessible by integration" (those are permission problems).
• PRs that were deleted along with their repository.

Steps

Step 1: Echo the exact query variables

echo "owner=[owner] name=[name] number=[number]"

Expected output: the three variables the GraphQL query actually sent. Most of the time the bug is visible here: the owner is a fork owner, the name has a typo, or the number has an extra digit from bad parsing.

Step 2: Check whether the number exists as a PR in that repo

gh pr view [number] --repo [owner]/[name]

Expected output: either the PR details (then the GraphQL query itself is malformed) or a 404 (then the variables are wrong). This splits the problem in half immediately.

Step 3: Check whether the number is an issue, not a PR

gh issue view [number] --repo [owner]/[name]

Expected output: if this shows an issue, you found it. Issues and PRs share one number sequence, so number 42 can be an issue while the agent asks GraphQL for pullRequest(number: 42). The fix is to query the right object type or use the right number.

Step 4: Check for the fork-vs-upstream mixup

gh pr view [number] --repo [upstream-owner]/[upstream-name]

Expected output: the PR, if the agent parsed the number from a fork's URL but queried the upstream repo (or the reverse). Cross-repo PRs live in the base repository. Query where the PR lives, not where the head branch lives.

Step 5: Fix the GraphQL query to use verified variables

query ($owner: String!, $name: String!, $number: Int!) {
  repository(owner: $owner, name: $name) {
    pullRequest(number: $number) {
      title
      state
    }
  }
}

Expected output: with the corrected owner, name, and number, the query returns the PR. Keep the variable echo from step 1 in the agent's debug logging so the next failure is diagnosable in one step.

Step 6: Add a pre-flight existence check to the review agent

gh pr view [number] --repo [owner]/[name] --json number --jq .number

Expected output: the PR number echoed back. Run this before the GraphQL batch in the review agent. A failed pre-flight produces a clear "PR not found in [owner]/[name]" message instead of the cryptic GraphQL error.

Variant phrasings

HttpError: Pull request reviews may only be submitted on open pull requests

Adjacent targeting error: the PR exists but is closed or merged. Check state before posting the review.

pr decoration failed: could not find pull request for commit

Same family: the commit is not associated with any PR in the queried repo. Check which repo and branch the commit actually belongs to.

GraphQL could not resolve to an Issue with the number of

The mirror image of this error. Same steps, querying issue(number:) instead.

Why it happens

GraphQL's repository.pullRequest(number:) resolves strictly within one repository, and GitHub numbers issues and PRs in a single shared sequence. Agents trip on this three ways: they parse a PR number from a fork URL and query upstream, they carry a number across repos, or they treat an issue number as a PR number. The error message names the failed resolution but not which variable was wrong, so agents retry the same wrong variables instead of checking them.

Edge cases

• A PR number from a deleted repository can never resolve. Verify the repo still exists before debugging the number.
• GitHub Enterprise Server slugs can differ from github.com. An owner or name that works on one host may not exist on the other.
• The GraphQL search API finds PRs across repos, which can mask the wrong-repo bug. Prefer the direct repository.pullRequest path with verified variables.
• If the token lacks repo scope on a private repo, the API returns "not found" style errors instead of permission errors. Rule out auth before concluding the number is wrong.
• Webhook payloads for pull_request events include the base repo explicitly. Prefer the payload's repo over any parsed URL.

Provenance

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