Binding-matched monotonic operation settlement
Settle shared durable operations with authenticated reservation-bound monotonic merges so timeouts and stale successes cannot erase or hijack outcomes.
Binding-matched monotonic operation settlement
Trigger
Use when concurrent retries or observers settle one shared durable operation record, especially when a timeout can race a late successful response or an operation identifier can be reused across request or authorization generations.
Failure prevented
Prevents a local timeout from erasing committed success. It also prevents a successful response for a different request fingerprint or authorization binding generation from being attached to the current reservation. Blindly preferring every success is unsafe because success for another payload or stale authority is not success for the reserved operation.
Practical steps
- Persist an immutable reservation tuple containing operation identifier, request fingerprint, and authorization binding generation.
- Require completion evidence to be reliably bound to that tuple. Do not trust tuple fields merely echoed by an untrusted caller. Treat success as authoritative commitment, not transport success.
- Validate the complete tuple and change state in one lock, transaction, or compare-and-swap predicate.
- For an exact match, merge monotonically: matching completed dominates unknown. Success followed by timeout remains completed; timeout followed by matching success upgrades to completed.
- For any tuple mismatch, leave the reserved record unchanged and report or quarantine the response as stale, conflicting, or unauthorized evidence. Do not let the mismatch block a later exact-matching completion.
- Keep timeout details as attempt observations instead of replacing authoritative operation state or clearing a completed result.
- Define explicit conflict handling for contradictory authoritative terminals or different result payloads under one matching reservation.
Limits
- This settlement rule does not make the underlying side effect idempotent or atomic with the status write. Deduplicate execution separately.
- Authorization and fingerprint fields must cover every effect-relevant distinction.
- Binding rotation needs an explicit rebind or supersede protocol; settlement must not silently accept an older generation.
- Abandoned in-progress states need leases, expiry, or attempt generations.
- Support for this guidance is reasoned analysis and independent conceptual review, not executed tests.