Skip to content

fix: detect synthetic weekly quota exhausted state#1619

Merged
looplj merged 2 commits into
looplj:unstablefrom
djdembeck:fix/synthetic-quota-exhausted-status
May 10, 2026
Merged

fix: detect synthetic weekly quota exhausted state#1619
looplj merged 2 commits into
looplj:unstablefrom
djdembeck:fix/synthetic-quota-exhausted-status

Conversation

@djdembeck

Copy link
Copy Markdown
Contributor

Purpose/Goal: Fix synthetic weekly token quota never reporting exhausted state, causing requests to leak through to upstream provider instead of being blocked by AxonHub.

Why

The synthetic weekly token quota was never reporting "exhausted" state even when usage reached 100%, causing requests to leak through to the upstream provider instead of being blocked by AxonHub.

What Accomplished

  • Added explicit check for usageRatio >= 1.0 to set status as "exhausted"
  • Updated Ready field to return false when quota is exhausted
  • Test updated to verify correct exhausted state detection

Spirit/Intent

Ensure AxonHub properly enforces synthetic token quota limits by correctly detecting and blocking requests when the weekly quota is fully consumed, preventing unauthorized upstream calls and protecting against quota exhaustion.

- Add usageRatio >= 1.0 check to set status='exhausted' and Ready=false
- Previously only checked WarningThresholdRatio, missing exhausted state
- Requests leaked through to upstream provider instead of being blocked
- Update test to verify exhausted status and Ready=false for weekly limit
@greptile-apps

greptile-apps Bot commented May 10, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR fixes a bug where the synthetic weekly token quota never reported an "exhausted" state, even when usage reached 100%, allowing requests to leak through to the upstream provider instead of being blocked.

  • Core fix in synthetic_checker.go: Adds usageRatio >= 1.0 check to weeklyTokenLimitStatus and replaces the hardcoded Ready: true with IsReadyStatus(status), so the weekly limit now correctly blocks traffic when fully consumed.
  • Consistency refactoring in claudecode_checker.go and nanogpt_checker.go: Replaces the inline status != \"exhausted\" expression with the shared IsReadyStatus helper, which is functionally equivalent for the reachable statuses in those code paths.
  • Test in synthetic_checker_test.go: Corrects the exhausted-state assertions from \"warning\" / Ready: true to \"exhausted\" / Ready: false, directly covering the reported bug.

Confidence Score: 5/5

Safe to merge — the fix is minimal, targeted at a clear gap in exhausted-state detection, and the refactored IsReadyStatus calls are semantically identical to the inline expressions they replace.

The weekly quota exhausted detection bug (Ready: true hardcoded, no usageRatio >= 1.0 check) is correctly addressed. The IsReadyStatus refactoring in claudecode_checker.go and nanogpt_checker.go is functionally equivalent because the only reachable status values in those functions are "available", "warning", and "exhausted" — no edge case is introduced. The test directly exercises the fixed code path with percentRemaining: 0.0.

No files require special attention.

Important Files Changed

Filename Overview
internal/server/biz/provider_quota/synthetic_checker.go Core bug fix: adds usageRatio >= 1.0 exhausted detection and replaces hardcoded Ready: true with IsReadyStatus(status) in weeklyTokenLimitStatus; semantically correct for all reachable statuses.
internal/server/biz/provider_quota/claudecode_checker.go Replaces status != "exhausted" with IsReadyStatus(status) for consistency; functionally equivalent since the only reachable statuses are "available", "warning", and "exhausted".
internal/server/biz/provider_quota/nanogpt_checker.go Same IsReadyStatus consistency refactoring as claudecode_checker; equivalent behavior for all reachable status values in this code path.
internal/server/biz/provider_quota/synthetic_checker_test.go Test assertions corrected from "warning" / Ready: true to "exhausted" / Ready: false in the exhausted-state test, directly validating the fix.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[weeklyTokenLimitStatus called] --> B{PercentRemaining nil?}
    B -- Yes --> C[status = available\nusageRatio = 0.0]
    B -- No --> D[usageRatio = 1.0 - percentRemaining/100]
    D --> E{usageRatio >= 1.0?}
    E -- Yes --> F[status = exhausted]
    E -- No --> G{usageRatio > WarningThresholdRatio?}
    G -- Yes --> H[status = warning]
    G -- No --> I[status = available]
    F --> J[IsReadyStatus: false]
    H --> K[IsReadyStatus: true]
    I --> L[IsReadyStatus: true]
    C --> L
    J --> M[QuotaLimitStatus returned\nReady: false — blocks upstream]
    K --> N[QuotaLimitStatus returned\nReady: true — allows upstream]
    L --> N
Loading

Reviews (2): Last reviewed commit: "refactor(quota): use IsReadyStatus helpe..." | Re-trigger Greptile

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the weeklyTokenLimitStatus function to correctly identify and handle exhausted quotas by setting the status to 'exhausted' and the Ready flag to false when the usage ratio is 1.0 or greater. The associated unit tests were also updated to verify this behavior. Feedback suggests using the IsReadyStatus helper function for the Ready field to maintain consistency and improve code maintainability.

Status: status,
UsageRatio: usageRatio,
Ready: true,
Ready: status != "exhausted",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

For better consistency and maintainability, use the IsReadyStatus helper function defined in types.go instead of hardcoding the status check. This ensures that the logic for determining if a quota is 'ready' remains centralized and consistent with other parts of the codebase, such as the parseResponse function.

Suggested change
Ready: status != "exhausted",
Ready: IsReadyStatus(status),

Replace status != "exhausted" with IsReadyStatus(status) in
synthetic_checker, nanogpt_checker, and claudecode_checker for
consistency with the rest of the codebase.
@looplj looplj merged commit f899fb1 into looplj:unstable May 10, 2026
4 checks passed
@djdembeck djdembeck deleted the fix/synthetic-quota-exhausted-status branch May 11, 2026 05:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants