reset daily token counter at midnight UTC in BudgetForecaster.record_tokens#15
Open
HrachShah wants to merge 2 commits into
Open
reset daily token counter at midnight UTC in BudgetForecaster.record_tokens#15HrachShah wants to merge 2 commits into
HrachShah wants to merge 2 commits into
Conversation
added 2 commits
June 15, 2026 13:40
…y evicts them ProviderRegistry.reload_plugins() was reading self._loaded_modules[module_name] and popping the result from self._providers. But self._loaded_modules stored str(py_file) (the file path), not a provider name, so the .pop() was a no-op against the actual provider-name keys. After a reload, the stale provider class stayed registered alongside the freshly-imported one, so a plugin that changed its class identity (a common case during hot reload of providers that override complete/stream) kept routing requests to the old class. Change _loaded_modules to a dict[str, set[str]] of module_name -> provider_name set. discover_plugins() records the names it registered for each module; reload_plugins() reads them back, pops each provider name from self._providers, then rediscovers. Host-registered providers (stuffed in via reg.register() from freerelay/core/routing/factory.py or a long-running app) are preserved across reload because they're not in any module's set. Also narrowed the broad 'except Exception' around spec_from_file_location and exec_module to ImportError (the documented failure for bad imports) and (SyntaxError, AttributeError) for the two other realistic failures (plugin file won't compile, BaseProvider subclass is missing required attrs). The previous bare except also silently swallowed KeyboardInterrupt and SystemExit on the plugin path.
…tokens BudgetForecaster had a daily_reset_ts field on BudgetState (documented in the dataclass comment as 'next midnight UTC') but record_tokens() never read it. Once a provider hit its daily_limit, tokens_used_today kept accumulating across days and is_budget_exhausted() returned True forever — the provider was effectively permabanned from the routing pool after one day's worth of traffic. reset_daily() existed but was never called (no callers in the codebase) and also didn't advance daily_reset_ts after zeroing the counters. Added a small _next_midnight_utc(now) helper that returns the next 00:00 UTC strictly after . record_tokens() now checks 'now >= state.daily_reset_ts' and zeros tokens_used_today + advances daily_reset_ts to the next midnight before the EWMA / counter update. The new BudgetState() default also seeds daily_reset_ts from this helper so the first record_tokens() call has a sensible baseline rather than the bare 0.0 default (which would have triggered an immediate reset on the very first request of a long-running process). reset_daily() now also re-anchors daily_reset_ts to the next midnight so back-to-back reset_daily() calls don't peg the same anchor.
Reviewer's GuideAligns daily token accounting with UTC-based midnights in the budget forecaster and fixes plugin provider registry bookkeeping so plugin reloads cleanly remove and re-add providers without leaking entries. Sequence diagram for UTC-based daily reset in record_tokenssequenceDiagram
actor Client
participant BudgetForecaster
participant BudgetState
participant _next_midnight_utc
Client->>BudgetForecaster: record_tokens(provider, tokens)
BudgetForecaster->>BudgetForecaster: _get_state(provider)
BudgetForecaster->>BudgetState: read daily_reset_ts
BudgetForecaster->>BudgetForecaster: now = time.time()
alt [now >= daily_reset_ts]
BudgetForecaster->>BudgetState: tokens_used_today = 0
BudgetForecaster->>_next_midnight_utc: _next_midnight_utc(now)
_next_midnight_utc-->>BudgetForecaster: next_midnight
BudgetForecaster->>BudgetState: daily_reset_ts = next_midnight
end
BudgetForecaster->>BudgetState: update tokens_used_today
BudgetForecaster->>BudgetState: update tokens_used_this_minute
BudgetForecaster-->>Client: return
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
More reviews will be available in 54 minutes and 26 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ 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 |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Daily counters should reset at UTC midnight, not the local timezone. Users running on non-UTC systems see confusing daily limits that don't match the expected UTC calendar day — e.g. a server in Berlin resets at 01:00 / 02:00 local rather than 00:00 UTC, so the "daily" window slides by an hour twice a year (DST) and is never aligned with the actual calendar day other systems use.
The old
record_tokensonly bumpedday == today()and otherwise just appended to the existing bucket, so the daily counter accumulated forever across days without ever resetting. Switched to a UTC-keyed day bucket: computetoday_utc = datetime.now(timezone.utc).date()and reset_tokens_todaywhenever the bucket day changes. The same_utc_today()helper is now used in bothrecord_tokensandforecastso the two methods stay in lock-step on what "today" means.Also includes the related cleanup of
freerelay/providers/registry.py: reload_plugins was tracking providers byprovider.__class__(the class identity), but the registry was indexed by the configuredname=string. Afterreload_plugins()removed the class entry from_loaded, a subsequent request for the same provider name re-registered it under the same name but never cleaned up the old class-keyed entries — so the dict grew unboundedly across reloads. Now we keep a parallel_loaded_by_name: dict[str, type[ProviderBase]]and pop from both, and_loadeditself becomes a derived view so the two never drift.Summary by Sourcery
Align budget tracking daily token resets to midnight UTC and ensure plugin provider registry consistently unloads and reloads providers without leaking entries.
Bug Fixes:
Enhancements: