Root cause (surfaced by a downstream consumer's audit — latent since inception, not a regression): forceRotateForPlanChange is wired only into handleSubscriptionUpdated's plan-change block. handleCheckoutCompleted and both branches of handleSubscriptionCreated never rotate the current-week quota snapshot after a mid-week plan activation — the org keeps the previous plan's weekly quota until the next weekly reset (money bug: an upgraded org does not get its new quota immediately).
Fix:
- Wire the snapshot rotation into
handleCheckoutCompleted and both handleSubscriptionCreated branches (preserveUsage semantics consistent with the existing plan-change call site; rotation failure logged non-fatal, mirroring existing patterns).
- Usage attribution reads the LIVE quota rather than the stale snapshot where applicable (
billing.usage.service.js).
- Integration tests: checkout-completed and subscription-created lifecycle paths assert the rotated snapshot + immediate new-plan quota.
Reference: a proven equivalent patch runs in production on a downstream consumer; this issue ports it to the stack so every consumer gets it.
Root cause (surfaced by a downstream consumer's audit — latent since inception, not a regression):
forceRotateForPlanChangeis wired only intohandleSubscriptionUpdated's plan-change block.handleCheckoutCompletedand both branches ofhandleSubscriptionCreatednever rotate the current-week quota snapshot after a mid-week plan activation — the org keeps the previous plan's weekly quota until the next weekly reset (money bug: an upgraded org does not get its new quota immediately).Fix:
handleCheckoutCompletedand bothhandleSubscriptionCreatedbranches (preserveUsagesemantics consistent with the existing plan-change call site; rotation failure logged non-fatal, mirroring existing patterns).billing.usage.service.js).Reference: a proven equivalent patch runs in production on a downstream consumer; this issue ports it to the stack so every consumer gets it.