Fix rate-limit dialog firing on 200 responses + skip Details enrichment when anon#508
Conversation
… routine remaining=0 on 200
…s to preserve 60/hr quota
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
WalkthroughThis PR enhances rate-limit detection to recognize HTTP 429 (in addition to 403) as rate-limited responses, adds a ChangesRate Limit Handling Enhancement
Details Repository Token-Gated GitHub Enrichment
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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. Review rate limit: 6/8 reviews remaining, refill in 8 minutes and 26 seconds.Comment |
Two related fixes for the residual rate-limit dialog on Details screen.
1. `RateLimitInterceptor` was firing global dialog on successful responses
The interceptor parses `X-RateLimit-Remaining` from every direct GitHub response. When the value reaches 0 (anon tipped over the 60/hr boundary), `rateLimitRepository.updateRateLimit` was emitting `rateLimitExhaustedEvent` even on 200 responses. `MainViewModel` collects that event and pops the global `RateLimitDialog` ("Resets in 31 minutes").
Result: user sees the dialog after a successful Details load, because the secondary GitHub enrichment call tipped `remaining` to 0 on its way back with valid data.
Fix: `updateRateLimit` now takes an explicit `notifyExhausted` flag. Interceptor only sets it true on actual error responses (403/429). State tracking (the `StateFlow` that powers the rate-limit indicator chip) still updates on every response. Domain interface signature backward-compatible — default value preserves existing behavior at the type level for any other callers.
2. Details `getRepoStats` enrichment burns anon's 60/hr for openIssues/license
`DetailsRepositoryImpl.getRepoStats` calls backend first (provides stars/forks/downloads), then makes a direct GitHub call to enrich with `openIssues` and `license` fields that backend doesn't expose. For anon users, this single enrichment call is 1/60 of their hourly budget — for a non-critical UI field. Cached stale value falls through gracefully on absence.
Fix: gate the enrichment on `tokenStore.currentToken()`. Signed-in users (5000/hr quota) keep getting enriched stats. Anon users skip it entirely — backend stats only. `openIssues` falls back to stale cache or 0; `license` falls back to stale cache or null. Same UX as if the GitHub call had failed silently.
Better long-term: ask backend to add `openIssues` and `license` to `/v1/repo` so signed-in users don't need this either. Tracked separately.
Test plan
Independent of #505/#506/#507 in scope. Branches off main.
Summary by CodeRabbit