Stop usage chips flashing and back off retries for failing providers#8772
Conversation
Two behaviors made the status bar unusable when any provider was persistently failing (bad auth, unsupported plan): 1. Every refetch repainted all providers as 'fetching', so a settled error chip flashed to a loading "…" chip and back on every cycle. withFetchingStatus now keeps settled states (ok/error/unavailable) visible until the new result lands; only providers with no settled state (first load, explicit account-switch clear) show loading. 2. Error providers on the fast activation-retry lane (claude/codex/ grok) were retried every 30s on any focus/show/restore event — forever. Repeated hits drove Claude's tight-budget usage endpoint into 429s, flipping the chip between 'Limited' and its actual error. Retries now back off exponentially per consecutive applied failure (30s, 60s, 120s, … capped at the 15-minute poll cadence) and reset on success or account/target switch.
|
Warning Review limit reached
Next review available in: 9 seconds 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: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds per-provider consecutive failure streak tracking to drive exponential backoff for active-window retry fetches when a provider is in an error state, capped by new constants. Streaks reset on Codex/Claude account or target changes and update after each fetch cycle (full, Codex-only, Claude-only, Grok-only) based on result status. The fetching-status helper now preserves already-settled ok, error, or unavailable states instead of overwriting them during background refetches. Tests are renamed and expanded to cover backoff window doubling, streak reset after recovery, and prevention of transient fetching status flashes. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 52ba70c0-54a0-472b-8513-8818457cd041
📒 Files selected for processing (2)
src/main/rate-limits/service.test.tssrc/main/rate-limits/service.ts
… feedback - Stamp failing providers' activation-retry clocks when a stale-driven full fetch runs, so the individual failure lane does not fire a redundant retry right after the full fetch already retried them. - GrokUsagePane: manual refresh spinner/disable is now renderer-local, since settled snapshots no longer repaint as 'fetching' during refetches. - Strengthen the backoff-reset test so it distinguishes a reset streak from a stale retry timestamp (CodeRabbit), and add a regression test for the full-fetch retry stamping.
1 participant
Problem
When any usage provider is persistently failing (bad auth, unsupported plan), the status bar becomes a permanent light show — captured on video: chips flip to a loading "…" state for 15+ seconds, flash an error ("Refresh failed" / "Refreshing sign-in" / "Limited"), then flip back, forever. Two mechanisms cause it:
fetching— a settled error chip with no data renders as the loading "…" chip for the whole in-flight window (15s when Codex burns its hidden-PTY timeout), then flashes back to the error.codexPTY under the main process lasting exactly 15s. The repeated bursts also drove Claude's tight-budget OAuth usage endpoint into 429s, flipping its chip between "Limited" and its underlying error.Fix (service-level only, no renderer changes)
withFetchingStatuskeeps settled states (ok/error/unavailable) visible until the new result actually lands. Only providers with no settled state (first load, explicit account-switch clears, MiniMax credential invalidation) show the loading chip.refresh()force paths) is untouched — user-initiated recovery stays immediate.Testing
fetchingduring background refetches (regression test for the flash).vitest runrate-limits + status-bar suites — 469 tests pass;typecheck:tsc:nodeclean.Related
Companion fixes for the underlying provider failures: #8765 (Codex auth classification), #8767 (Claude stale scoped keychain), #8769 (Grok unified billing).