# Fix "Could not resolve to a PullRequest with the number of N" in GitHub GraphQL

## TL;DR

The number you passed is almost never a pull request. Issues and pull requests share one number sequence per repository, so this error fires when the number names an *issue*, when you queried the wrong repo (most often a fork, because `gh` infers the repo from your local git remote), or when your token cannot see the repo at all. The error text does not tell you which of these it is, so run the diagnostic steps below in order.

## The exact error

```text
GraphQL: Could not resolve to a PullRequest with the number of 337. (repository.pullRequest)
```

When you run it through the `gh` CLI you see the same thing on stderr:

```text
GraphQL: Could not resolve to a PullRequest with the number of 337.
```

## Diagnose and fix, in order

### 1. Check what the number actually is

Issues and PRs share one number space, so `#337` might be an issue. Ask GitHub which it is:

```sh
gh api repos/OWNER/REPO/issues/337 --jq '{number: .number, is_pr: (.pull_request != null)}'
```

Expected output:

```json
{"number": 337, "is_pr": false}
```

If `is_pr` is false, the number is an issue: use `gh issue view 337`, or `repository { issue(number: 337) { ... } }` in GraphQL. Note the trap in the other direction: `gh issue view` *succeeds* on pull request numbers because GitHub models a PR as a kind of issue, so it cannot discriminate. Only `gh pr view` can tell you the number is not a PR.

### 2. Pin the repo context

`gh` resolves the repository from your local git remote when you do not say which repo. If you checked out a fork, `gh pr view 337` looks for the PR in the fork, not the base repo, and you get this exact error. Pin it:

```sh
gh pr view 337 --repo OWNER/REPO
```

Expected: the PR title, state, and URL print normally. If it works with `--repo` but not without, your repo context was wrong. In CI workflows always pass `--repo ${{ github.repository }}` explicitly.

### 3. Accept either object type in raw GraphQL

If your code pulls numbers from commit messages or comment payloads, it will eventually be handed an issue number. Query the union instead of `pullRequest(number:)`:

```graphql
query($owner: String!, $repo: String!, $num: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequestOrIssue(number: $num) {
      __typename
      ... on PullRequest { title url }
      ... on Issue { title url }
    }
  }
}
```

Expected: `__typename` tells you which object the number actually names, so the code path branches correctly instead of failing.

### 4. Rule out visibility and repo problems

If the repository itself cannot be resolved you get a sibling error:

```text
GraphQL: Could not resolve to a Repository with the name of 'owner/repo'.
```

GitHub answers this both for a repo that does not exist and for a private repo your token may not read, so you cannot tell the two apart from the message alone. Check that the token has access to the repo and, on GitHub Enterprise Server, that you are pointing at your GHES hostname rather than github.com. A rejected or expired credential answers differently (401 bad credentials), which is a different problem with a different fix.

### 5. In GitHub Actions: guard `issue_comment` events

The `issue_comment` event fires for comments on issues *and* on pull requests with the same payload shape. A workflow that takes the comment's parent number and resolves it as a PR will fail on every plain issue comment with this error. Gate the job on the PR-only trigger, or on the presence check `github.event.issue.pull_request` being non-null (it is set only when the parent is a pull request):

```yaml
if: >-
  github.event_name == 'pull_request_target' ||
  (github.event_name == 'issue_comment' && github.event.issue.pull_request)
```

## When this skill applies

- `repository.pullRequest(number:)` or `gh pr view N` fails with "Could not resolve to a PullRequest with the number of N"
- A workflow extracts `#NNN` from commit messages, PR bodies, or `issue_comment` payloads and resolves each number as a PR
- A CI job fails with this error only on fork PRs (the classic fork-context mismatch)
- Raw GraphQL code calls `pullRequest(number: N)` with a number from an untrusted or mixed source

## When it does NOT apply

- `gh: HTTP 401: Bad credentials`  -  that is a rejected or expired token, not a resolution failure
- The REST endpoint `GET /repos/{owner}/{repo}/pulls/{number}` returning 404 for a genuinely missing PR number  -  different API, different diagnostic
- "Could not resolve to an Issue with the number of N" when you meant to fetch a PR  -  invert the fix (use `pullRequest(number:)`)
- Rate limiting or abuse detection messages  -  backoff, not diagnosis

## Tool and version compatibility

- GitHub GraphQL API v4 (`api.github.com/graphql`) and GitHub Enterprise Server 3.x GraphQL endpoints
- `gh` CLI 2.x (the error surfaces through `gh pr view`, `gh pr comment`, `gh api`)
- Applies to tokens of any type (classic PAT, fine-grained PAT, `GITHUB_TOKEN`)  -  visibility depends on repo access and, for fine-grained tokens, the pull-requests/issues permission set

## Variant phrasings of this error

### "Could not resolve to an Issue with the number of N"

The mirror image: you passed a pull request number to `repository.issue(number:)`. Use `pullRequest(number:)` or the `pullRequestOrIssue` union from step 3.

### "Could not resolve to a Repository with the name of 'owner/repo'"

The repo itself cannot be resolved  -  wrong owner or name, wrong hostname (github.com vs GHES), or a private repo the token cannot read. Never stands in for a missing pull request; diagnose the repo first.

### "gh pr view" failing with the error but the PR visibly exists

Almost always the fork-context mismatch from step 2, or the token in your shell can see the repo while the token in CI cannot.

### REST twin: `GET /repos/{owner}/{repo}/pulls/{number}` returns 404

The REST pull endpoint also 404s for issue numbers. Diagnose the number with `gh api repos/OWNER/REPO/issues/N` first (step 1).

## Why it happens

GitHub numbers issues and pull requests out of a single sequence per repository, but the GraphQL schema gives them separate entry points: `issue(number:)`, `pullRequest(number:)`, and the union `pullRequestOrIssue(number:)`. When you query `pullRequest(number: N)` for a number that names an issue, GitHub has nothing to resolve the path `repository.pullRequest` to, and it reports the failure literally, without distinguishing "this number is an issue" from "wrong repo" from "your token cannot see this repo." The error therefore reads like a wrong number when the number was right and something else was wrong.

## Edge cases and pitfalls

- `#N` in a commit subject (like `fix: ... (#337)`) usually names the *issue* the commit closes, not the PR that carried it. Regex-extracting `#NNN` from commits and feeding it to `gh pr view` fails exactly this way.
- Comment payloads in `issue_comment` events carry the parent number in the same field for issues and PRs; always filter on the `pull_request` key before treating it as a PR number.
- Deleted pull requests and PRs in private repos you lost access to answer with the same message as a nonexistent PR; the error cannot prove absence beyond your token's visibility.
- On GitHub Enterprise Server the hostname matters: the same query against `github.com` for a GHES-only repo yields the repository variant of the error, not a useful auth message.
- `gh` version differences: older `gh` versions omit the trailing path (e.g. `(repository.pullRequest)`); the meaning is unchanged.