feat(usage): return API limit restriction state - #8492
Conversation
The usage dashboard cannot say what a restricted organisation has lost, whether a free organisation is at risk at all, or whether an overage can actually be charged. None of it is on any response. Adds stop_serving_flags, api_limit_restriction_enabled and overage_charges_enabled to the organisation response, each sharing its definition with the task that acts on it via a new organisations/services module, so the page cannot drift from what those tasks do. overage_charges_enabled corrects a live wrong message: overages are only billed on terms of roughly a month, so an annual Start-Up or Scale-Up organisation is currently told charges may apply when they cannot. Contributes to #8256 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (7)
💤 Files with no reviewable changes (3)
Included review availability: Your plan provides up to 8 included reviews per hour; 5 remain after this review. 📝 WalkthroughWalkthroughThe change adds a shared service for organisation API-limit restrictions. The grace-period task uses this service to update restriction state and send notifications. The organisation serializer exposes the computed restriction status. Frontend types and OpenAPI schemas include the new organisation fields. Unit tests cover service decisions, task behaviour, serializer output, and ignored restriction-field input. Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~25 minutes Merge Risk: ⚪ Minimal · up to The new organisation status fields and restriction logic are covered across service, task, and API serialization paths, with no concrete merge-blocking risk identified. ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8492 +/- ##
========================================
Coverage 98.82% 98.82%
========================================
Files 1622 1624 +2
Lines 66708 66981 +273
========================================
+ Hits 65923 66197 +274
+ Misses 785 784 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Whether an overage can actually be charged is not what #8256 asks for, and the usage dashboard epic puts overage cost out of scope. It also carries its own argument, that annual plans are never billed for overages, which deserves its own review rather than riding along here. Leaves this change to the one question the issue does ask: can this organisation be cut off. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Docker builds report
|
✅ private-cloud · depot-ubuntu-latest-arm-16 — run #20412 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)Details
🗂️ Previous results✅ private-cloud · depot-ubuntu-latest-16 — run #20412 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-16)Details
✅ oss · depot-ubuntu-latest-arm-16 — run #20412 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-arm-16)Details
✅ oss · depot-ubuntu-latest-16 — run #20412 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-16)Details
|
Visual Regression19 screenshots compared. See report for details. |
Thanks for submitting a PR! Please check the boxes below:
docs/if required so people know about the feature.Changes
Contributes to #8256
The usage page cannot say what a restricted organisation has lost, or whether a free organisation is at risk of being cut off at all. Two read only fields on the organisation response:
stop_serving_flagsapi_limit_restriction_enabledapi_limiting_*flag on for this organisationapi_limit_restriction_enabledshares its definition withrestrict_use_due_to_api_limit_grace_period_overthrough a neworganisations/servicesmodule, so the page and the task cannot drift apart. It compares the plan id tofreerather than using the plan family, to match that task, which means an organisation with no plan set reportsfalse.The grace period half of #8256 needs
OrganisationBreachedGracePerioduntangled first, and follows separately.How did you test this code?
Unit tests cover both fields across plan family, plan id, missing cache, missing subscription and each flag combination, that they stay read only, and a task case for an organisation reached with both flags off, which the previous inline version never exercised. Also checked by hand against a local API, walking a throwaway organisation through each state.