Repository navigation
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a narrowly scoped bug fix that makes the advisory rate-limit probe non-blocking for GitHub Enterprise while preserving the actual read and existing specialized error paths. The accompanying test verifies both successful reads and probe caching, with no product-default or static-analysis changes. Notes:
You can add or adjust custom eligibility rules. Learn more. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: pingdotgg/t3code/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe quota probe now suppresses ChangesGitHub CLI quota probe
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~8 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The change allows reads to proceed when Enterprise rate-limit probing is unavailable while preserving other error handling. It is mergeable after normal checks. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Dismissing prior approval to re-evaluate e188cfd
|
Note Grok responding on behalf of Julius. Superseded by #14673, which removed the REST |
On GitHub Enterprise servers with rate limiting disabled, the PR sidebar's Comments/Activity and stack views fail with "GitHub CLI command failed." while Checks still works. Before every
gh pr view,gh pr list, andgh repo view, T3 probesgh api rate_limit --hostname <host>. On those servers the probe returnsHTTP 404: Rate limiting is not enabled., and T3 treats that as fatal, so the real command never runs. Checks go straight through GraphQL and skip the probe, which is why they work.The probe only feeds the GraphQL budget, so it should never be the thing that fails a read. The quota lookup in
GitHubCli.tsnow treats a genericGitHubCliCommandErrorfrom the probe as "no quota information": the read runs, and that result is cached for the usual 30s so we don't re-probe on every call. Authentication, rate-limit, and missing-gherrors from the probe still come through as before. If the read itself fails, it reports its own error.Verification: a new test in
GitHubCli.test.tsmakes the probe fail with the GHES 404. Reads succeed, and the probe runs once across two reads. The test fails without the fix. I didn't test against a real GHES instance.