[Bug]: PR watching stops when the token cannot read a requested reviewer #19549

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server / GitHub pull request watching

Steps to reproduce

1. Use a GitHub App credential that can read a private organization PR, but receives FORBIDDEN for one of its requested reviewers.
2. Configure the T3 server to use that credential and start watching the PR.
3. The detailed PR read includes reviewRequests.nodes.requestedReviewer. GitHub returns usable partial PR data plus the field-level error below.
4. T3 treats the entire read as failed. After eight consecutive read failures, it stops watching the PR.

With the same credential and PR, a minimal query for PR identity/head succeeds. Adding this selection reproduces the permission error:

reviewRequests(first: 10) {
  nodes {
    requestedReviewer {
      __typename
      ... on User { login }
      ... on Team { slug }
    }
  }
}

Expected behavior

An unreadable requested reviewer should not prevent watching otherwise accessible PR information. T3 could show that reviewer metadata is unavailable and continue monitoring readable checks, comments/reviews, and conflicts.

A possible implementation is to isolate the optional reviewer lookup, or retry without it only when the GraphQL error is FORBIDDEN at the reviewRequests.nodes.*.requestedReviewer path. Other authentication/authorization failures should remain failures, and unreadable or missing CI information must not be interpreted as passing.

Actual behavior

Optional reviewer metadata makes the detailed PR read fail, eventually disabling the watcher even though other PR data is accessible. Refreshing the credential with the same permissions does not resolve this field-level denial.

Source inspection: gitHubPullRequestJson.ts includes reviewer metadata in the core PR query, and GitHubApi.ts classifies a GraphQL response containing these errors as failed despite partial data being present.

Impact

Major degradation: affected PRs cannot remain watched without changing credential permissions, even when the denied field is only reviewer metadata.

Version or commit

• Watcher failure observed on 0.0.46-nightly.20261014.3080.
• The field-level GitHub API denial was reproduced again after installing 0.0.46-nightly.20261014.3118; the same query/error-handling pattern is present in that release's source. I have not rerun a full watcher failure cycle on .3118.

Environment

Linux remote T3 server with macOS client; private organization repository; GitHub App credential. Repository, reviewer, and credential details omitted because they are private.

Logs or stack traces

Sanitized GitHub GraphQL error (the response also contains partial data):

{
  "type": "FORBIDDEN",
  "path": [
    "repository",
    "pullRequest",
    "reviewRequests",
    "nodes",
    0,
    "requestedReviewer"
  ],
  "extensions": {
    "saml_failure": false,
    "ip_allow_list_failure": false
  },
  "message": "Resource not accessible by integration"
}

Workaround

No reliable in-app workaround found. We have left the affected watcher stopped. We have not established which additional GitHub permission would expose this reviewer, and would prefer that optional metadata not require broader access.

Related work

• fix(pull-requests): pull request detail opens when the token cannot read checks #16171 proposes graceful handling of unreadable checks, but does not remove the requested-reviewer dependency.
• fix(github): requested teams now show in pull request reviewers #19375 adds requested-team display support, but does not handle a forbidden reviewer field.
• GitHub CLI has a related field-overfetching report: gh pr edit --title fails when a team reviewer is inaccessible to the token cli/cli#14317.