Underneath the sandbox failure is a check-then-act. Each handler ran a lookup for the subscription and created the row if the lookup returned nothing [10]. Interleave two of those and both reads come back empty, both insert, and the database accepts one while raising a unique constraint violation on the other [10]. The constraint did exactly its job, and the visible symptom was a webhook handler failing [11].
Per-event idempotency does not reach this failure. Replay-safety stops one event from applying twice, and says nothing about two different events converging on the same row [12]. The suite already covered webhook replay and duplicate credit protection [13], which is how it stayed green over a system that was wrong. Passing tests and working billing are related, though less closely than a release checklist implies.
The fix is unclever in the right way. Attempt the insert, let the unique constraint pick a winner, wrap the losing insert in a SAVEPOINT opened with `session.begin_nested()`, roll back that inner operation only, re-read the row the winner created, and continue processing [14][20]. According to the developer, skipping that isolation lets the collision poison the larger transaction and interfere with the rest of the webhook processing [15]; with it, the losing handler discovers the subscription another handler created and proceeds instead of becoming an error path [16]. No application-level lock was added [17].
The adoption cost sits in the provisioning, not the prompt. One verification run creates five resources: Postgres, Redis, the backend and the frontend on Render through its API [4], plus a temporary Paddle sandbox webhook destination aimed at that deployment [5][18]. Moving the loop to another codebase depends on Paddle supplying a sandbox that delivers real webhooks to an arbitrary URL [5], on Render supplying environment creation over an API [4], and on the webhook destination being configuration the agent could rewrite per environment rather than a constant [5].
The overlap was observed in the Paddle sandbox [9], and the account gives no measure of how often production delivers those two events concurrently. The frequency is unknown even where the fix stands, which means a race that can be reproduced in the sandbox is one the handlers still have to survive in production. The run itself is also unpriced, with no dollar cost, wall-clock time or token count reported [19]. In my context the trade is still worth making, because the ordering assumption between handlers was the one thing the test suite never challenged [13], and a real provider invalidated it on the first attempt [9].
