Two clients retry the same durable operation. One observes a committed success and settles completed; the other later times out and settles unknown. Plain last-write-wins can replace completed with unknown and lose success.
Question: what settlement rules keep a committed success durable across both completion orders—success then timeout, and timeout then success—without treating wall-clock write order as authority?
Known: shared operation record; timeout is an observer outcome, not a stronger fact than commit. Unknown: whether the store exposes compare-and-swap, status ranks, or only blind overwrites.
Resolution (reasoning only; no executed tests; no repository or machine configuration inspected).
Root cause: wall-clock last-write-wins ranks every settlement write equally. A local timeout is observer-indeterminate, not an authoritative rollback of a committed outcome. When a late timeout writes unknown after a peer wrote completed, LWW erases success.
Settlement rule: merge by a monotonic status lattice, not by writer time. Rank observer-unknown below in-progress below reservation-matching terminal. A timeout may write only unknown and must never outrank a matching committed terminal. Matching committed success outranks unknown in both orders.
Both completion orders:
- Success then timeout: store completed; late unknown is a no-op or stays subordinate; record remains completed.
- Timeout then success: store unknown first; later matching completed upgrades via merge; record becomes completed.
Evidence each writer must attach: outcome class (committed success, committed failure, or observer-local timeout), and for terminals an exact match on the reserved tuple operationid plus requestfingerprint plus binding_generation. Attach authoritative result payloads only on reservation-matching committed paths. Implement as conditional update or merge(stored, incoming), never blind overwrite.
Caveat: prefer-success is unsafe without the binding check. A late completed that shares only the operation id but not fingerprint or binding generation must be rejected or quarantined, not merged as success over the reserved record.
Limits: unknown means local indeterminate state, not server rollback; this does not atomically couple side effects with status writes; completed versus failed under one reservation needs an explicit join or conflict terminal.
New failure mode (reasoning only; no executed tests; no repository or machine configuration inspected).
A late writer reports completed with the correct durable operationid, but a different requestfingerprint and/or binding_generation than the tuple locked when the op was reserved.
Strengthened locked settlement: apply the monotonic status lattice only after an exact reservation match. Before promoting any terminal, require stored reservation equals incoming (operationid, requestfingerprint, binding_generation).
On match: unknown or observer-timeout still loses to committed success; matching completed upgrades prior unknown. On mismatch: reject or move to an explicit conflict or quarantine state that freezes ordinary lattice merges; do not store completed over the reserved record.
Why blindly preferring every successful response is unsafe: operation_id alone is not identity of the intended request or principal. Concrete corruptions include (1) id reuse or collision settling a different payload as if it were the reserved work, (2) a client that mutated the request after reserve so the late success is for different inputs, (3) a stale grant from a prior binding generation applying effects under obsolete credentials. Preferring any completed response authorizes that mismatch and can grant the wrong work or wrong principal.
Correct check order: compare fingerprint and binding generation first; only then apply status merge. Matching committed success remains monotonic over observer timeout; mismatched success does not outrank reservation or a matching terminal.