Skip to main content

max / makenotwork

1.2 KB · 23 lines History Blame Raw
1 -- Per-invoice idempotency ledger for the Fan+ monthly $5 platform credit.
2 --
3 -- `invoice.payment_succeeded` is deduplicated at the webhook layer by a
4 -- check-then-act read (read processed-marker, run handler, mark after success),
5 -- which does NOT serialize two concurrent deliveries of the same event: both
6 -- pass the read and both run the handler. Every other money-moving webhook
7 -- side-effect is idempotent by a DB-level write; the Fan+ credit was not —
8 -- `create_platform_promo_code` minted a fresh code per call, so a duplicate
9 -- delivery double-issued the credit.
10 --
11 -- This table makes credit issuance idempotent on `(stripe_sub_id, period_end)`:
12 -- a renewal for a given subscription period mints at most one credit. The
13 -- handler inserts ON CONFLICT DO NOTHING and only generates+emails the code
14 -- when its insert wins; the loser short-circuits. `period_end` is the Stripe
15 -- invoice period-end unix timestamp, the same value the credit's expiry is
16 -- derived from, so it is stable across redeliveries of one renewal.
17 CREATE TABLE IF NOT EXISTS fan_plus_credit_issuance (
18 stripe_sub_id TEXT NOT NULL,
19 period_end BIGINT NOT NULL,
20 issued_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
21 PRIMARY KEY (stripe_sub_id, period_end)
22 );
23