I maintain a couple of open-source libraries for exactly-once execution — the problem where an agent retries a tool call after a timeout, doesn't know whether the first attempt landed, and ends up doing it twice. A charge, a message, a payment. Nothing crashes. It just happens twice.
Part of the work is reading other people's MCP servers looking for this exact bug, and yesterday I found one: a payments tool that signs and sends a transaction on every call, with no idempotency key anywhere in its schema. I opened an issue. I proposed a fix: derive a default key from the URL, the amount, and the wallet, so a retried request collapses into one settlement.
A stranger replied and told me my fix was wrong.
Not wrong in a nitpick way. Wrong in a way that would have been worse than the bug I was reporting. My key was too narrow — it only looked at three fields. Two offers for the same resource, at the same price, from the same wallet, but with a different payee, network, or asset, are different payments. My derivation would have collapsed them into one key. Which means: a legitimate second purchase would have silently returned the first purchase's receipt.
Sit with that for a second, because it's the part that made me actually stop and think. A double-charge is bad, but it's visible. Someone sees two line items and files a dispute. A swallowed purchase looks like a success. The buyer thinks they paid and got the thing. Nobody investigates a transaction that appears to have worked.
