fix(billing): derive meterQuota from live plan config, not stale DB snapshot#3667
Conversation
…napshot Mirror of trawl_node#1174 to keep devkit Node parity and prevent the next /update-stack from wiping the downstream patch (per feedback memory update_stack_theirs_wipes_patches). Bug: getUsage controller returns `meterQuota: meter?.meterQuota ?? 0`. The DB doc's `meterQuota` is a snapshot baked at last `incrementMeter` time, so it stays at the old plan's quota (e.g. 10 for free) after the user upgrades, until the next scrap run. UI reads the stale snapshot instead of the live config. Fix: derive meterQuota from BillingPlanService.getActivePlan(plan)?.meterQuota with a fallback to the DB snapshot if the live config returns null (unknown plan id) and 0 as last resort. Tests cover: - growth plan returns 1600 (live) even when DB snapshot shows 10 - unknown plan falls back to DB snapshot - both unavailable → 0
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3667 +/- ##
==========================================
+ Coverage 89.54% 89.71% +0.17%
==========================================
Files 138 142 +4
Lines 4733 4784 +51
Branches 1472 1500 +28
==========================================
+ Hits 4238 4292 +54
+ Misses 388 385 -3
Partials 107 107
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
Updates the billing usage endpoint to report meterQuota from the live plan configuration (instead of a potentially stale BillingUsage DB snapshot) so upgraded orgs immediately see the correct quota in meter mode.
Changes:
getUsagenow derivesmeterQuotafromBillingPlanService.getActivePlan(plan)?.meterQuota, with fallback to the DB snapshot and then0.- Added unit tests covering: live quota override after upgrade, fallback for unknown plans, and
0when neither source is available.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| modules/billing/controllers/billing.controller.js | Derives meterQuota from live plan config in meterMode rather than the stored snapshot. |
| modules/billing/tests/billing.usage.endpoint.unit.tests.js | Adds unit coverage for live quota override + fallback behavior in meterMode. |
…fig missing Addresses review: getUsage silently fell back to the DB snapshot/0 when getActivePlan returned null, masking plan/config mismatches. getUsage is a read-only display endpoint (not a gate — billing.requireQuota already fails safe with 503 on the work path), so it degrades gracefully but now emits a warn log for ops visibility. Comment updated to document the fallback.
Summary
Mirror of comes-io/trawl_node#1174 (already merged) to keep devkit Node parity and prevent the next
/update-stackfrom wiping the downstream patch — per memoryfeedback_update_stack_theirs_wipes_patches.Bug
getUsagecontroller returnedmeterQuota: meter?.meterQuota ?? 0. The DB doc'smeterQuotais a snapshot baked at lastincrementMetertime, so it stays at the old plan's quota (e.g.10for free) after the user upgrades to growth (1600), until the next scrap run actually mutates the snapshot. UI reads the stale snapshot instead of the live config — Bug #5/#6.Fix
Derive
meterQuotafromBillingPlanService.getActivePlan(plan)?.meterQuotawith a fallback to the DB snapshot when the live config returns null (unknown plan id), and0as last resort.Test plan
1600(live) even when DB snapshot shows100Phase 0 critical-review
Same change as trawl_node#1174 (Phase 0 verdict: OK with nits — medium follow-up about logging when
getActivePlanreturns null is tracked separately).