Retries, replay, and business outcomes

The response can disappear after success

Imagine a checkout request that reaches the application, creates an order, and loses its response on the way back. The customer sees an uncertain result and retries. From the customer’s perspective the retry is reasonable; from the application’s perspective the operation may already be complete.

Now compare that with a captured request being replayed by another caller. The repeated bytes may look similar, but the intended application behavior is different. A request-integrity control and an operation-recovery mechanism need to cooperate without being mistaken for the same mechanism.

Replay protection belongs to proof use

Verification can reason about whether proof is being used consistently with its current state. That helps the system make a decision about an incoming request. It does not automatically reveal whether an order was committed after an earlier decision.

A verification service should not be presented as the owner of application state it does not control. An accepted request can still fail a stock check, be denied by a payment provider, or encounter a database error before the operation completes.

Idempotency belongs to the operation

The application needs a deliberate way to recognize repeat attempts at the same operation and return an appropriate stored outcome. That is an application contract involving identity, operation scope, and consistent state changes; it is not a property obtained merely by adding a browser credential.

An idempotency mechanism also needs authorization. Knowing an operation identifier should not let a different account retrieve its result or alter its request. The application must preserve its account and tenant boundaries when looking up earlier outcomes.

For limited inventory, consistency matters at the point of allocation. Browser verification cannot make a non-atomic stock update atomic or decide how long a reservation should be held.

Keep decisions and outcomes separate

Record enough application state to distinguish an operation that was rejected, one that never started, one that completed, and one whose result has not yet been reconciled. The specific model depends on the operation; a verification decision alone is not that model.

The MANDATE Reroute development work explores a scoped request path while keeping authentication, operation intent, and stored outcomes in the design. It remains default-off with release validation pending. A changing path grants no authority and does not remove the application’s obligations.

Test the uncertain middle

A useful integration review includes more than a clean success and a clean rejection. Exercise a lost response after completion, a duplicate attempt, an expired proof, and an authenticated caller asking for a result it does not own.

The expected result should be stated in application terms: one stored order, the existing reservation returned to its owner, or a clear failure that did not change state. That is how request-level evidence becomes part of a reliable customer journey.