feat(checkout): add delete of checkout records by billing account - #1841

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontier	Ready	Preview	Aug 5, 2026 2:47am

No actionable comments were generated in the recent review. 🎉

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 @coderabbitai help to get the list of available commands.}

End-to-end testing of the whole stack

Posting here because this is the PR that lands on main, so it carries the whole series.

Tested at the tip of the stack, which contains all six PRs: #1841 → #1842 → #1843 → #1844 → #1838 → #1839. That covers checkout delete, credit delete, kyc delete, the retryable subscription teardown, the deleter changes, and the new checkout audit records.

Run against a real Stripe test-mode account, so every provider call actually went to Stripe. No mock and no recorded cassettes.

Setup

• Fresh Postgres and SpiceDB databases, both migrated from scratch.
• Platform permissions, roles, platform users and preferences applied with frontier reconcile.
• A Stripe test-mode key in billing.stripe_key.
• One plan created through CreatePlan ($10/month, 100 start credits). Frontier registered the product and price in Stripe.
• Seven orgs seeded through the normal RPCs to cover the different billing shapes. Billing accounts, usage, checkout sessions and KYC records were all created the way a client would create them.
• Every delete was driven through FrontierService/DeleteOrganization.
• After each delete I checked three places: the local tables, the auditlogs rows, and the Stripe API directly.

Results

Extra checks:

• Orphan sweep across the whole database after all deletes: 0 orphaned checkouts, subscriptions, invoices, KYC rows and billing accounts.
• Unit tests pass for all five changed packages.

What the retry case showed

I forced a realistic mid-teardown failure with a trigger on billing_customers. The behaviour matched what the code comments claim:

• Checkouts and credit rows were removed and the audit records were written.
• The org row survived and kept its owner policy, so the org was still owned and still reachable.
• After removing the trigger, the same call finished the delete.
• The checkout audit count stayed at 2. Retrying does not write duplicate records, because the checkout list is empty the second time.

Audit record contents

Each app.billing.checkout.deleted record carried the Stripe session id (cs_test_...), the customer id, the plan id, the state and the payment status. Six checkouts were removed across the test orgs and six records were written, one each. So the sessions can still be traced on the provider after the local rows are gone, which is the point of #1839.

Two issues found, neither introduced by this stack

1. A refused delete looks like a crash to the caller. When the invoice guard blocks a delete, the client gets:

{"code":"internal","message":"internal server error"}

The real reason never reaches the caller. internal/api/v1beta1connect/deleter.go wraps every error as CodeInternal, so deleter.ErrDeleteNotAllowed is lost and a normal business rule reads as a server fault. Mapping that error to CodeFailedPrecondition would fix it. Can raise this separately.

2. Credit ledger rows on the system account stay behind. Each usage debit writes two rows: one on the customer account and one on the system account (00000000-0000-0000-0000-000000000000). DeleteByAccountID clears the customer side only, so the system-side rows remain and still carry descriptions naming orgs that no longer exist. Nothing breaks and the customer delete is not blocked, since there is no foreign key on billing_transactions.account_id. Flagging it because it leaves the ledger one-sided. It may well be intended for accounting history.