fix(billing): keep the synced invoice amount up to date - #1906
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedNext included review available in 47 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review. 📝 WalkthroughSummary by CodeRabbit
WalkthroughInvoice synchronization now detects provider total changes, including changes to zero. The invoice repository writes the invoice amount during updates. ChangesInvoice synchronization
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🔵 Low · up to The PR updates stored invoice totals, including valid zero amounts, fixing stale billing data. If synchronization and reconciliation overlap, an older provider snapshot could temporarily overwrite a newer total in local billing and deletion-preflight views, while provider-side deletion checks remain authoritative. The change is mergeable with owner awareness or follow-up on update ordering. Suggested reviewers: 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
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 |
Coverage Report for CI Build 33153602246Coverage decreased (-0.007%) to 49.161%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
c453bec to
f6974a6
Compare
The invoice sync only ever updated the state, effective date, and hosted URL of an existing local row — the amount stayed frozen at whatever the first sync saw. A draft that Stripe created empty and filled with usage later kept amount 0 locally forever, so everything reading the local rows saw wrong totals: billing pages showed stale numbers, and the org delete check skipped a real unpaid invoice and enabled a delete the server then refused. The sync now writes the total when it changes, and the repository update includes the amount column. Zero is a real value (a draft whose items were credited away), so it is written like any other total.
f6974a6 to
ddab84e
Compare
3 participants
Found through review on #1881 (#1881 (comment)): the invoice sync's update path only ever wrote
state,effective_at, andhosted_urlon an existing local row. The amount was frozen at whatever the first sync saw.Concrete failure: Stripe creates next month's invoice as an empty draft, our sync stores it with amount 0, Stripe fills it with usage to a real total — and the local copy says 0 forever. Everything reading local rows inherits the lie: billing pages show stale totals, and
CheckOrganizationDeleteskips the invoice (its non-zero filter sees 0), so the delete button promises a delete the server then refuses against live provider data.The fix is the sync writing the total when it changes, plus the repository update actually including the
amountcolumn. Zero is a real total (a draft whose items were credited away), so it is written unconditionally rather than behind a not-set guard; bothUpdateByIDcallers pass full invoice rows.What this deliberately does not solve: an open invoice fully covered by the customer's credit balance still has a positive total with nothing due, so the delete check can grey the button until the provider marks it paid (minutes, self-clearing, and in the safe direction). Storing
amount_remaininglocally would close that too — filed separately as a follow-up.🤖 Generated with Claude Code