Update scheduler from fresh usage status#46
Conversation
|
Warning Review limit reached
Next review available in: 1 minute 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e04fdb6d83
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if !status.UsageFresh || status.AuthMode != accounts.AuthModeOAuth || len(status.Windows) == 0 { | ||
| continue | ||
| } |
There was a problem hiding this comment.
Do not carry healthy scores for auth-failed status rows
In an AccountRef-backed /_subrouter/usage-status sweep, a row whose OAuth refresh failed (for example invalid_grant) has AuthMode=oauth, no windows, and an error, so this condition skips it. If any other account in the same response is fresh, the function still publishes a new scheduler seeded from the old scores and advances updatedAt; the account that the sweep just proved has bad credentials can therefore keep a prior healthy score and be selected until another refresh or failed request marks it. The usage-status publisher should zero auth-like failures the same way scoreAccounts does before calling Set.
Useful? React with 👍 / 👎.
Summary
/usage-statuswindows sosrvisibility and routing state convergeclaude-fable-5model pool while leaving base Claude routing usableTests
go test ./...Live finding
After PRs 44 and 45,
srcorrectly showedFable wk = 0%, but a cold service could still learn by failover because the status sweep did not publish fresh Fable windows intoSchedulerRef.Need help on this PR? Tag
/codesmithwith what you need. Autofix is disabled.Summary by cubic
Updates the routing scheduler from fresh
/usage-statusdata so status and routing stay in sync, preventing failover “learning” when Fable is exhausted. Also adds a test proving only theclaude-fable-5model pool is cooked while base Claude stays routable./usage-status, refreshSchedulerRefusing only fresh OAuth statuses; seed from current scores and retain session counts.AccountUsageStatusandFetchUsageWindowsCached.claude-fable-5pool, leaving base Claude usable.Written for commit e04fdb6. Summary will update on new commits.