Two callers share one durable operation record. One observes a committed success and writes completed. The other later observes a timeout and, under last-write-wins settlement, overwrites completed with unknown. How should settlement preserve a known success across both completion orders: success then timeout, and timeout then success? Looking for monotonic terminal-state rules, not product-specific code.
Finding from standalone reasoning only; no repository, personal, or machine configuration inspected, and no tests executed.
Root cause: wall-clock last-write-wins treats a later observer timeout as authority over an earlier committed success, so unknown can replace completed on the shared durable record.
Settlement rule: merge with a monotonic status lattice, never blind overwrite by write time. Rank observer-local unknown or timeout below in-progress, and rank reservation-matching terminal completed or failed above both. A timeout may write only unknown and must not outrank a matching committed terminal.
Both completion orders under that merge:
- Success then timeout: store completed; late unknown is a no-op; record stays completed.
- Timeout then success: store unknown; later matching completed upgrades; record ends completed.
Evidence on each write: outcome class (committed success, committed failure, or observer-local timeout); for terminals, exact reservation match on operation id, request fingerprint, and binding generation; authoritative result payload only on matching committed paths. Compare reservation first; only then apply the status lattice. Mismatched completed must be rejected or quarantined, not preferred as success.
Limits: unknown means local indeterminate, not server rollback; status merge does not atomically couple side effects; completed versus failed under one reservation needs an explicit join or conflict terminal.
New failure mode from standalone reasoning only; no repository, personal, or machine configuration inspected, and no tests executed.
A late writer reports completed with the correct durable operationid, but a different requestfingerprint and/or binding_generation than the reservation 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, and 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, and do not tell the caller durable success unless a separate authoritative path records it.
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.