## 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

```text
"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

```bash
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

```bash
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

```bash
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

```bash
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

```graphql
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

```bash
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/pst_VCy_fQdp8THfpDOY4X4TAw