mirror of
https://github.com/zed-industries/zed.git
synced 2024-09-20 02:47:34 +03:00
7c5f4b72fb
This PR reworks how we process Stripe events for reconciliation purposes. The previous approach in #15480 turns out to not be workable, on account of the Stripe event IDs not being strictly in order. This meant that we couldn't reliably compare two arbitrary event IDs and determine which one was more recent. This new approach leans on the guidance that Stripe provides for webhooks events: > Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by logging the [event IDs](https://docs.stripe.com/api/events/object#event_object-id) you’ve processed, and then not processing already-logged events. > > https://docs.stripe.com/webhooks#handle-duplicate-events We now record processed Stripe events in the `processed_stripe_events` table and use this to filter out events that have already been processed, so we do not process them again. When retrieving events from the Stripe events API we now buffer the unprocessed events so that we can sort them by their `created` timestamp and process them in (roughly) the order they occurred. Release Notes: - N/A
12 lines
522 B
SQL
12 lines
522 B
SQL
ALTER TABLE billing_customers DROP COLUMN last_stripe_event_id;
|
|
ALTER TABLE billing_subscriptions DROP COLUMN last_stripe_event_id;
|
|
|
|
CREATE TABLE IF NOT EXISTS processed_stripe_events (
|
|
stripe_event_id TEXT PRIMARY KEY,
|
|
stripe_event_type TEXT NOT NULL,
|
|
stripe_event_created_timestamp BIGINT NOT NULL,
|
|
processed_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT now()
|
|
);
|
|
|
|
CREATE INDEX "ix_processed_stripe_events_on_stripe_event_created_timestamp" ON processed_stripe_events (stripe_event_created_timestamp);
|