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
22 lines
447 B
Rust
22 lines
447 B
Rust
use super::*;
|
|
|
|
pub mod access_tokens;
|
|
pub mod billing_customers;
|
|
pub mod billing_subscriptions;
|
|
pub mod buffers;
|
|
pub mod channels;
|
|
pub mod contacts;
|
|
pub mod contributors;
|
|
pub mod dev_server_projects;
|
|
pub mod dev_servers;
|
|
pub mod embeddings;
|
|
pub mod extensions;
|
|
pub mod hosted_projects;
|
|
pub mod messages;
|
|
pub mod notifications;
|
|
pub mod processed_stripe_events;
|
|
pub mod projects;
|
|
pub mod rate_buckets;
|
|
pub mod rooms;
|
|
pub mod servers;
|
|
pub mod users;
|