fix: Fix PR review tools (except create_pull_request_review which works already) when authenticated with a GitHub App installation token (S2S)

[Copilot]

Summary

Creating a pending PR review (create_pull_request_review tool or pull_request_review_write tool with method: create) works when authenticated with a GitHub App installation token.

However, the other PR review related tools don't work, becuase they try to use the GraphQL API to find the current pendig review, and this API doesn't behave correctly for bot actors.

This fixes it by identifying the pending review using the REST API rather than the GraphQL API. Everything else stays the same.

Why

When authenticated with a GitHub App installation/server-to-server token, GitHub uses the app's bot user as the "viewer" and review author.

The initial create operation works because it creates a review directly on the pull request and does not need to rediscover it.

The subsequent operations receive only the repository and pull request number, so they must first look up the current caller's pending review:

• add_comment_to_pending_review / add_pull_request_review_comment
• submit_pending / submit_pending_pull_request_review
• delete_pending / delete_pending_pull_request_review

That lookup currently fails with an installation token. Live testing showed that the review is successfully created and is visible through REST as PENDING, but the GraphQL API's viewerLatestReview returns null. The follow-up tools therefore report that no pending review exists and cannot comment on, submit, or delete it.

We can revisit whether the upstream behavior/API should change for bot viewers, but the MCP server needs to behave correctly with the public APIs available today.

What changed

• For operations that need an existing pending review, list pull request reviews through REST with per_page=100, following pagination until the caller-visible PENDING review is found.
• Use the REST review's GraphQL node_id with the existing GraphQL comment, submit, and delete mutations.
• Apply the hybrid lookup to both consolidated and granular pull request review tools.
• Cover pagination, missing reviews, submitted-only reviews, missing node IDs, REST failures, and the existing GraphQL mutations.

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Tool schemas and response text are unchanged. Existing pending-review operations now work when authenticated with GitHub App installation/server-to-server tokens and acting as the app's bot user.

Prompts tested (tool changes only)

• "Create a pending review on this pull request."
• "Add an inline comment to the pending review on package-lock.json."
• "Submit the pending review as a comment."

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

The live workflow used a GitHub App installation/server-to-server token with pull request write access, causing requests to act as timrogers-github-app-testing[bot]. REST only exposes pending reviews to their author, so selecting the visible PENDING review does not require login normalization. Review listing is paginated at 100 reviews per request and continues until the pending review is found.

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint — passed with 0 issues.
• Tested locally with ./script/test — passed, including the full race-enabled suite.

Additional validation:

• Targeted hybrid lookup and mutation tests passed, including a pending review located on page 2.
• go build -o /tmp/github-mcp-server-branch ./cmd/github-mcp-server passed.
• A GitHub App installation token completed two live workflows on timrogers/iata-code-decoder-api#1446:
  • Existing pending review: inline comment, then submitted review.
  • Fresh end-to-end review: create pending review, add inline comment, then submit review. REST verification showed the review in COMMENTED state and the comment attached to that exact review.

Docs

• Not needed
• Updated (README / docs / examples)

No tool schema, tool name, configuration, or user-facing workflow changed.

[Copilot]

Copilot review overview

🟡 Changes recommended

The REST error path can leak response bodies and eventually exhaust connections.

Review effort: Balanced
Findings: 1

Open (1)

• Close REST response before returning on error · New

What changed in this PR

Enables pending pull-request review operations for GitHub App installation tokens by using REST review lookup with existing GraphQL mutations.

Changes:

• Finds pending reviews through paginated REST requests.
• Applies the lookup to consolidated and granular tools.
• Adds pagination and failure-path tests.

File	Description
pkg/​github/​pullrequests.go	Adds REST pending-review lookup.
pkg/​github/​pullrequests_test.go	Tests lookup, pagination, and errors.
pkg/​github/​pullrequests_granular.go	Integrates REST lookup into granular tools.
pkg/​github/​granular_tools_test.go	Updates granular comment test setup.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[timrogers]

I looked into the possibility of fixing this in the GitHub API, but it looks like the complexity would be high.

In the API, viewer currently never supports GitHub App installation actors, so we'd have to make a big change there or introduce a special field to solve this case.

The implementation here, leaning on REST, feels like the practical solution.

[timrogers]

After more digging into the monolith code and what's going on here, I don't think this is the right approach. I'll think on it some more.

[Aziz1144]

Пиши мне в телефон телеграмм вапсап

[rananisarsb51214]

copilot/bot-pending-pr-reviews