Start with the write path, because that is where this design either holds or does not. A callback arrives carrying a code and a state value. The handler does not open by exchanging the code. It opens by claiming the attempt: one atomic transition on the stored flow record that establishes who owns the work before any side effect runs [4]. A second request for the same state loses that transition, reads the outcome already recorded, and returns the same application-level destination [5]. It must not provision the user again, issue another internal session, or append an audit event asserting a second login [5].
The author is blunt that HTTP cannot promise exactly once on its own, so the guarantee moves to the business boundary, where unique constraints reject duplicate effects and an outbox carries committed work to asynchronous consumers [6]. Delivery can still be at least once; effects cannot [6]. The audit trail records transitions rather than secrets, so the useful line says flow af_7d31 went from pending to exchanging and that callback attempt 3 saw a transport timeout [7]. Codes, tokens and session cookies stay out of logs [8], which everyone agrees with until an incident call asks for the raw callback URL.
Classification comes before backoff, and the ordering is the whole argument. A connection timeout is ambiguous, a validation rejection is terminal for that attempt, and an abandoned browser is an expired attempt that can be closed without inventing an error [9]. Two of those three need no retry at all [10]. That is why wrapping the flow in a generic exponential-retry helper is the wrong shape [9]. Caps, jitter and a deadline tied to the attempt's expiry protect dependencies from a retry wave, and the author is explicit that they do not create idempotency [11]. For an unknown token exchange, the recommended move is not a second exchange but persisting the ambiguity, blocking parallel exchanges, and sending the user into a fresh flow [12].
One boundary gets different treatment. Deletion and session revocation are not one remote call: the local transaction marks the account deletion-pending, advances or invalidates the session generation, rejects future token refreshes, and enqueues cleanup, and only then do workers revoke remote grants and erase dependent data [14]. The stated reason is ordering risk, since erasing data while a live session can still act is the more dangerous sequence [15]. The retention period itself the author hands to counsel and the data inventory, not to the retry loop [16].
The asymmetry underneath all of it: callback delivery is replayable because the application owns the receiver, while authorization is an interaction with a person, and a worker may retry the callback-side database transaction under a stable operation key [13]. In my read, that puts the retry budget on the database side of the boundary and nowhere near the redirect. This is one practitioner's design argument with no measurements attached, so what has to be true for it to transfer is narrow: a store that can do the claim and the effect in one transaction [4][6], a callback receiver you control [13], and an authorization code you treat as consumable exactly once [12].
