| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
This is a blocker to our workflow. Currently we are unable to resolve threads automatically through MCP using Claude, for example, because it does not know the IDs of the threads. Excited to see this PR and hope it can be approved soon. |
Sorry, something went wrong.
Cherry-picks upstream PR github#2245. Without the thread ID, resolve_thread / unresolve_thread are unusable. Drop this patch when upstream merges.
|
Supporting this PR. This is exactly the gap that #2229 identified — |
Sorry, something went wrong.
Cherry-picks upstream PR github#2245. Without the thread ID, resolve_thread / unresolve_thread are unusable. Drop this patch when upstream merges.
There was a problem hiding this comment.
As the reporter of #2229, I checked out this branch, built it locally, and verified the
behavior.
Verified:
One suggestion: the existing test for get_review_comments already provides "id" in the
mock data but never asserts thread.ID in the validation. Adding an assertion like
assert.Equal(t, "RT_kwDOA0xdyM4AX1Yz", thread.ID) would prevent silent regressions in
the future.
Sorry, something went wrong.
Cherry-picks upstream PR github#2245. Without the thread ID, resolve_thread / unresolve_thread are unusable. Drop this patch when upstream merges.
|
Is there anything that can be done to push this forward? I ran into the exact same issue just now, trying to resolve a PR thread via ai agent and was not able to without relying on gh to fetch the id via graphql. |
Sorry, something went wrong.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Restore the thread id field to MinimalReviewThread so that pull_request_review_write with method: resolve_thread / unresolve_thread is actually usable.
Why
#2062 dropped id from the minimized review-thread output, noting it was "not used for any subsequent tool call". While this was true at the time, #1919 later added resolve_thread / unresolve_thread, both of which require a thread node ID. The tool's own docstring reads:
…but that tool no longer returns them, so there's no way to resolve a thread without leaving the MCP server. This results in callers of this tool being unable to resolve threads through the resolve_thread tool.
The GraphQL query (reviewThreadNode in pkg/github/pullrequests.go) already fetches ID — it's just dropped during minimization.
Also see: #2229
What changed
MCP impact
Prompts tested (tool changes only)
Security / limits
Tool renaming
Docs
Fixes #2331