Fix: read all three PR comment surfaces in the fix-pr skill - #1512
Conversation
fetch-comments queried only reviewThreads, so review summary bodies and PR conversation comments were never fetched. A CHANGES_REQUESTED rationale or a plain "please rebase" comment could therefore sit unread while the fix-pr loop reported the PR clean. - Fetch reviewThreads, reviews[].body, and issue comments in one query - Track handled review bodies and conversation comments in a per-PR ledger, since neither surface carries an isResolved bit and both would otherwise re-present as unaddressed every iteration - Filter bot status/walkthrough noise, and dedup summaries that only restate their own inline threads - Answer non-thread feedback with a batched PR conversation comment; resolveReviewThread stays thread-only, as it rejects review and issue-comment node IDs - Require no unhandled feedback on any surface before the loop exits
|
Warning Review limit reached
Next review available in: 7 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Summary
fetch-commentsqueried onlyreviewThreads, so thefix-prloop wasstructurally blind to two of the three surfaces a PR carries feedback on. A
CHANGES_REQUESTEDreview body or a plain "please rebase" conversation commentcould sit unread while the loop reported the PR clean.
reviewThreads.nodesisResolved)reviews.nodes[].bodyCHANGES_REQUESTEDrationale, bot summariescomments.nodes@-mentionsChanges:
lib/github/fetch-comments.md— one query for all three surfaces; per-PRhandled-ID ledger for B/C (neither carries an
isResolvedbit, sore-fetching would re-present answered feedback forever); bot noise filter and
a dedup rule for summaries that only restate their own inline threads.
lib/github/reply-and-resolve.md— split by surface. A keeps reply +resolveReviewThread; B/C get a batchedgh pr commentwith an@loginmention, since that mutation rejects non-thread node IDs.
skills/fix-pr/SKILL.md— Step 2 fetches and counts all three; the exitcondition now requires no unhandled B/C items; Step 4 classifies every
surface (a
CHANGES_REQUESTEDbody is actionable by default — it blocksmerge even with all threads resolved); Step 5 labels items by surface;
Step 7 covers reply-without-resolve.
Testing
markdownlint-cli2 --config tests/lint/.markdownlint.yamlclean on all four filesjqsurface splits verified against PR Add: AICore fault triage to the device error code guide #1501,which returns 0 unresolved threads but 1 review body + 3 conversation
comments — exactly the blind spot this fixes
grep -Fxv -f) — passes all IDs through