feat(flare_git): add pr_status action for terse, resolution-aware PR review data - #268
Conversation
…ents Review-and-fix loops previously needed separate pr_get, run_list, and raw comment/review API calls per PR. pr_status fetches PR detail, CI check runs, review verdicts (incl. bot reviewers like CodeRabbit), line comments, and issue-level comments in one MCP round trip, and returns a single JSON payload. Known limitation: the REST API has no isResolved field for review threads (GraphQL-only), so review_comments includes resolved threads too -- callers should use judgment on older/superseded ones.
Two problems with the first pass: REST has no thread-resolution field at all (only GraphQL's reviewThread.isResolved), so old-but-fixed review comments were indistinguishable from live ones; and every call re-fetched full comment history with no way to ask for just what's new. - pulls::resolved_review_comment_ids: GraphQL lookup of resolved review-thread comment ids; pr_status filters review_comments against it so only unresolved (still-outstanding) ones survive. - since (ISO8601) on GitHubRequest, threaded into the REST comment fetches (both support ?since= server-side) so repeated pr_status calls only pull what's new since the caller's last check. - Output trimmed to what a fix loop actually needs: passing checks become a count instead of a list, reviews dedupe to one entry (the latest) per reviewer, and timestamps/html_url/redundant fields are dropped entirely.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (5)
📝 WalkthroughWalkthroughAdds GitHub models and endpoints for pull request checks, reviews, review comments, resolved threads, and issue comments. Adds status JSON aggregation and exposes the combined data through the MCP ChangesPull request status
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant MCPClient
participant flare_git_impl
participant GitHubAPI
participant pr_status_json
MCPClient->>flare_git_impl: pr_status(number, since)
flare_git_impl->>GitHubAPI: Fetch PR, checks, reviews, and comments
GitHubAPI-->>flare_git_impl: Return status data and resolved IDs
flare_git_impl->>pr_status_json: Aggregate status data
pr_status_json-->>MCPClient: Return serialized PR status
Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/github/pulls.rs (2)
106-145: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSilent truncation risk in the resolved-thread GraphQL query.
reviewThreads(first:100)/comments(first:50)caps are documented as an accepted tradeoff, but the query never requestspageInfo, so hitting the cap is undetectable. For a PR with more than 100 review threads (or >50 comments in one thread), already-resolved comments beyond the cap silently fall out ofresolved_ids, causing them to reappear as "unresolved" inpr_statusoutput.Requesting
pageInfo { hasNextPage }onreviewThreads(and ideally oncomments) is a small addition that would let callers at least detect/log truncation, ahead of implementing real cursor pagination.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/github/pulls.rs` around lines 106 - 145, The resolved_review_comment_ids GraphQL query cannot detect when its reviewThreads or per-thread comments limits truncate results. Add pageInfo { hasNextPage } to both reviewThreads and comments, then inspect those flags after parsing and surface truncation through the existing error/logging mechanism available to this function, while preserving the current resolved-ID collection behavior.
87-105: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winSame since-filtered pagination pattern duplicated across
pulls.rsandissues.rs. Both functions repeat an identical "conditionally append?since=..., then paginate and parse" sequence; the shared root cause is the lack of a common helper for optional-sincepaginated GETs.
src/github/pulls.rs#L87-L105: extract thesince-append +get_paginated+serde_json::from_valuesequence inlist_review_commentsinto a shared helper.src/github/issues.rs#L72-L91: reuse the same helper inlist_commentsinstead of duplicating the sequence.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/github/pulls.rs` around lines 87 - 105, Extract the shared optional-since paginated GET and JSON parsing flow from list_review_comments in src/github/pulls.rs (lines 87-105) into a common helper, preserving query encoding and GitHubError parsing. Update list_comments in src/github/issues.rs (lines 72-91) to reuse that helper instead of duplicating the sequence; both sites require these changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/github/pulls.rs`:
- Around line 106-145: The resolved_review_comment_ids GraphQL query cannot
detect when its reviewThreads or per-thread comments limits truncate results.
Add pageInfo { hasNextPage } to both reviewThreads and comments, then inspect
those flags after parsing and surface truncation through the existing
error/logging mechanism available to this function, while preserving the current
resolved-ID collection behavior.
- Around line 87-105: Extract the shared optional-since paginated GET and JSON
parsing flow from list_review_comments in src/github/pulls.rs (lines 87-105)
into a common helper, preserving query encoding and GitHubError parsing. Update
list_comments in src/github/issues.rs (lines 72-91) to reuse that helper instead
of duplicating the sequence; both sites require these changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 23da1fe5-31e7-494e-8003-8ef7f5e0becc
📒 Files selected for processing (8)
src/github/actions.rssrc/github/issues.rssrc/github/mcp.rssrc/github/models.rssrc/github/pulls.rssrc/mcp_server.rssrc/mcp_server/flare_git.rssrc/mcp_server/types.rs
Summary
pr_statusaction to theflare_gitMCP tool that bundles PR detail, CI check runs, review verdicts, review comments, and issue comments into one call — replacing the 4-5 separateflare_gitround trips a review-and-fix loop previously needed.reviewThread.isResolved(REST has no such field) so old-but-fixed comments don't get re-surfaced as outstanding.since(ISO8601) that's passed to GitHub's native?since=filter on both comment endpoints, so repeated calls only pull what's new.checks_okcount, reviews dedupe to the latest verdict per reviewer, and timestamps/redundant fields are dropped.Test plan
cargo build,cargo clippy --workspace --all-features -- -D warnings,cargo test --workspace --all-featuresall cleangithub::(11 new: models, actions, pulls incl. GraphQL resolved-ids + since-query, issues, mcp assembly)#[ignore]d test — confirmed correctmergeable_state, failing-checks list,checks_okcount, emptyunresolved/reviews, and CodeRabbit's summary comment coming through intact (test was reverted before commit, not part of the suite)Summary by CodeRabbit
pr_statusaction to fetch pull request details, CI check runs, reviews, review comments, and issue comments in a streamlined JSON response.since).pr_statusinputs and comment filtering behavior.