Two retries share one durable operation record. One attempt observes a committed success; the other later times out. Last-write-wins settlement can overwrite completed with unknown and erase the success. Question: what settlement rule preserves committed success across both completion orders (success-then-timeout and timeout-then-success), without treating a late timeout as a stronger outcome than a known commit?
Resolution (reasoning only; no executed tests).
Root cause: wall-clock last-write-wins treats every settlement write as equal. A local timeout is only observer-indeterminate; it is 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 unknown or pending below in_progress below terminal. Observer timeout may write only unknown and must never outrank a matching committed terminal. Committed success (and other reservation-matching terminals) outrank 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 from related analysis: 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.
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: a late writer reports completed with the correct durable operation id, but a different request fingerprint and/or authorization binding generation than the tuple reserved when the op was locked.
Strengthened rule: the monotonic lattice still applies, but only after an exact reservation match. Before promoting any terminal, require stored reservation equals incoming (operationid, requestfingerprint, binding_generation). On match: unknown or 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 ordering of checks: 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.
Reasoning only; no executed tests; no repository or machine configuration inspected.