fix: handle GitHub rate limit during governance audit#102
Conversation
github-actions
Bot
added
bug
|
Warning Review limit reached
Next review available in: 41 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: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughThe ChangesAudit rate-limit detection and error banner
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant GovernancePage
participant AppContext
participant GitHubAPI
GovernancePage->>AppContext: runAudit()
AppContext->>AppContext: reset error, rateLimitHit=false
loop batch of repos
AppContext->>GitHubAPI: fetchIssues(repo)
GitHubAPI-->>AppContext: result or RATE_LIMIT rejection
alt RATE_LIMIT detected
AppContext->>AppContext: rateLimitHit=true, break
end
end
AppContext->>AppContext: update issuesData, govLoading=false
alt rateLimitHit
AppContext->>GovernancePage: setError(rate-limit message)
end
GovernancePage->>GovernancePage: render error banner
GovernancePage->>AppContext: setError('') on dismiss
Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
github-actions
Bot
added
size/S
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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.
Inline comments:
In `@src/context/AppContext.jsx`:
- Around line 145-161: The batch fetch logic in AppContext’s repository loop
only checks Promise.allSettled results for RATE_LIMIT and silently ignores every
other rejection, leaving missing repos with no visibility. Update the
fetchIssues batch handling to inspect all rejected results, not just RATE_LIMIT,
and surface non-rate-limit failures through the existing error/reporting path
while still allowing the rate-limit early exit in the repos loop. Use the
Promise.allSettled block, hitLimit handling, and fetchIssues call site as the
key places to adjust.
- Around line 137-169: The shared `error` state in `AppContext` is used by both
`explore()` and `runAudit()`, so an error from one flow can incorrectly appear
in the other. Split this into separate state values for Explore and Governance
(or otherwise scope the message by flow), and update `runAudit` and the
explore-related logic to set/clear only their own error. Also clear the relevant
error when changing pages so stale banners don’t persist across routes.
In `@src/pages/GovernancePage.jsx`:
- Around line 156-163: Add an accessible alert role to the GovernancePage error
banner so screen readers announce the rate-limit message when it appears. Update
the conditional error block in GovernancePage.jsx where the error `<div>` and
`<span>{error}</span>` are rendered to include `role="alert"` on the banner
container, keeping the existing behavior and styling unchanged.
- Around line 164-170: The dismiss control in GovernancePage’s error banner is
an untyped <button> that can default to submit behavior; update the button in
the error-dismiss UI to explicitly set its type to a non-submit value. Use the
existing onClick handler and aria-label on the dismiss button as the anchor, and
make the type explicit so the banner cannot trigger accidental form submission
if it is rendered inside a form.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 946c0bd1-255d-4312-bccd-f8b2621c707f
📒 Files selected for processing (2)
src/context/AppContext.jsxsrc/pages/GovernancePage.jsx
github-actions
Bot
added
size/M
1 participant
Addressed Issues:
Fixes #81
Screenshots/Recordings:
Additional Notes:
Promise.allSettled was absorbing rejected promises silently. The audit loop now inspects each batch's results for RATE_LIMIT rejections. On detection, the loop breaks early (avoiding further doomed requests) and calls setError() with a user-friendly message — the same pattern already used by explore().
error from AppContext was only rendered on HomePage. Since users are on the Governance page when the audit runs, the error was set but never shown. The page now reads error and setError from context and renders a dismissible inline banner between the page title and stat cards — scoped to where the user's attention is after clicking "Run Audit".
Partial results collected before the rate limit was hit are preserved and still displayed.
Checklist
We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact.