Idempotency on Brian Faust

A Code Review Should Test the Decision, Not the Author

Thu, 01 Aug 2019 00:00:00 +0000

One booking flow could trigger the same automatic wallet refill twice. The first refill happened while booking. A later debit event ran the ordinary refill check again.

The correction wrote a short-lived marker per account containing the pending amount. When a matching shipment debit arrived, it consumed the marker and skipped one refill. Focused tests covered the expected sequence.

That is enough to begin a review, not finish one. A tidy helper and a green happy-path test can make the change look settled. The decision is not “is this cache helper elegant?” It is:

An Idempotency Key Is Not an Identity

Fri, 01 Jun 2018 00:00:00 +0000

A booking test sends the same request twice with the same idempotency key. The remote booking service is called once, and both callers receive the same successful response. Then one field changes while the key stays the same. The remote service is still called once, but the second request receives a conflict instead of the first result.

The key did not establish sameness. It only gave the application somewhere to look.

A Webhook Delivery Is Not a Unique Event

Tue, 01 May 2018 00:00:00 +0000

A subscription callback had already created this local record:

carrier: external-freight
subscription_id: sub-demo-17
secret: old-secret
expires_at: 2018-05-08T12:00:00Z

The sender delivered another validation message for sub-demo-17, now with a new secret and expiry. The handler tried to insert a second row. A unique constraint rejected it, so the activation step never ran.

The database was right to reject it. The handler had mistaken another delivery for another subscription, then treated the constraint as the problem.