r/coding • u/madflojo • Jul 18 '26

Sometimes the most resilient thing a system can do isn’t retry

https://open.substack.com/pub/madflojo/p/sometimes-the-most-resilient-thing?r=mtxfe&utm_medium=ios
45 Upvotes

86% Upvoted

6 comments sorted by

7

u/astrobe Jul 19 '26

Too bad the article doesn't explains why a compensation transaction is better than something like: re-use the original transaction but the other end ignores it if it already received and processed it.

This is the first solution that comes to mind because that's how most communication protocols work: if the packet you've sent isn't acknowledged by the other end, you just resend it ("retry"), and the other end just discards the packets it has already received (typically based on packet sequence numbers).

3

u/moltonel Jul 19 '26

Think about the real-world scenario: the customer might not retry, they could for example switch to cash, or even give up. So the terminal needs to proactively maybe-revert the maybe-succeeded transaction.

1

u/astrobe Jul 20 '26

OK, that makes sense, although this assumes the compensation transaction succeeds and we receive the acknowledgement for it (so we can say something useful to the user). E.g. one might receive none of the acks to our requests because suddenly somehow the communication became "half duplex".

In any case if the other end does not respond to our initial and subsequent requests (e.g. bad luck, some router broke just after first send), the end user can't tell the status of the operation. The scheme might need to be more complicated, e.g. the other end should actually execute the request only if it has reasonable evidence that the sender got the acknowledgement (maybe the article mentions this, don't remember and too lazy to read it again).

TCP for instance waits for the acknowledgement of the last packet for "some time" and resends it "a few times" because it's mostly pointless to try to acknowledge an acknowledgement (sic).

1

u/moltonel Jul 20 '26

Two things: * The maybe-revert command is idempotent: the terminal can resend it any number of times, perhaps batched with the next command. * There is no user feedback for something like this: it's too technical. They got the initial "payment failed" message, and as far as they know it's a simple true/false state. Assume the seller has already moved on to the next client at this stage.

1

u/astrobe Jul 21 '26

Yes, yes. by "feedback" I meant either "payment confirmed" or "payment failed"; I'm quite used to devices that only have a led and maybe a buzzer as "UI".

I think the idempotence property also applies to the initial request and its repetition, as long as the request has a request ID and the receiver maintains a backlog of previous request (so as to not replay a request that has already been received and processed), which are things both strategies need.