max / makenotwork

1.3 KB · 32 lines History Blame Raw

1	//! Purchase queries: the pending-transaction lifecycle, free claims, refunds
2	//! and cart settlement.
3	//!
4	//! A paid checkout writes a `pending` row before the buyer leaves for Stripe,
5	//! and completion flips it to `completed`; nothing else moves a row between
6	//! those states. A pending row that is never completed is deleted by the
7	//! caller who abandoned it, or by `cleanup_stale_pending` past the age the
8	//! scheduler passes it (25h), which returns any `promo_code_id` so the
9	//! reservation is released with the row.
10	//!
11	//! The dedup these queries lean on is a set of partial unique indexes on
12	//! `transactions`, one pair per subject:
13	//! `(buyer_id, item_id)` and `(buyer_id, project_id)`, each once for
14	//! `status = 'pending'` and once for `status = 'completed'`, and
15	//! `(guest_email, item_id)` for `status = 'completed'`. All are partial on
16	//! the id being NOT NULL, so a project purchase (NULL `item_id`) does not
17	//! collide with an item purchase. `ON CONFLICT DO NOTHING` and the 23505
18	//! backstops throughout this file name those indexes; changing one means
19	//! revisiting every claim and checkout path here.
20
21	mod checkout;
22	mod claims;
23	mod guest;
24	mod reads;
25	mod refunds;
26
27	pub use checkout::*;
28	pub use claims::*;
29	pub use guest::*;
30	pub use reads::*;
31	pub use refunds::*;
32