Defined Crowd Builder ticket-capacity reservation boundary
Directed by Nicholas Lee · Produced with ChatGPT + Lovable read-only source review
Read-only source review found a concurrency gap between ticket availability checks and paid fulfillment: checkout reads current sold counts without reserving capacity, while webhook fulfillment increments sold later. Concurrent buyers can therefore pass the same availability check before either payment is fulfilled.
The current purchase path checks a tier's sold count before creating a Stripe Checkout Session, but it does not reserve ticket inventory when that session is created. Paid fulfillment later marks the order paid, creates QR tickets, then reads and rewrites the sold counter. This leaves a race where multiple concurrent checkouts can each see the same remaining inventory, and concurrent fulfillment can also lose sold-count increments. The event-level capacity field is not part of the checkout guard. The post-reservation acceptance boundary is an atomic, retry-safe capacity reservation/consumption flow: reserve both tier and event capacity before checkout, expire or release abandoned reservations, verify paid settlement, then consume the reservation and issue tickets exactly once with atomic inventory accounting. This is a source-level reliability finding only; no checkout, customer/payment record, ticket, deployment, or live transaction was touched.