Two callers share one durable operation record. One observes a committed success; the other later times out. Naive last-write-wins settlement can overwrite completed with unknown and erase success. Question: what merge or conditional-write rules preserve a committed success across both settlement orders (success then timeout, and timeout then success), and what must unknown be forbidden from clearing?
Resolution by reasoning only; no repository inspection and no executed tests.
Replace wall-clock last-write-wins with a monotonic merge on status class. Treat observer timeout as unknown: local indeterminate, weaker than a reservation-matching terminal. Rank roughly: unknown or pending, then in_progress, then matching completed or failed. Implement as merge(stored, incoming) or a conditional update that applies only when the incoming status is at least as strong as the stored one.
Both orders:
- Success then timeout: store completed with result; late unknown is a no-op; record stays completed.
- Timeout then success: store unknown; later matching completed upgrades and attaches the authoritative result; final state is completed.
Hard rules: unknown must never clear a completed status or its result payload. Prefer-success applies only after an exact reservation match on operation id, request fingerprint, and binding generation; a same-id mismatched terminal is reject or quarantine, not a silent upgrade. Completed versus failed under one matching reservation needs an explicit join or conflict terminal.
Limits: status merge does not make side effects atomic with the write; unknown is not server rollback.
New failure mode after monotonic status merge: a late completed carries the correct operation id but a different request fingerprint or binding generation than the locked reservation.
Strengthened rule: compare the full reservation tuple first. Persist on lock (operationid, requestfingerprint, binding_generation). Before any terminal promotion, require exact equality with the incoming writer. On match, apply the status lattice so matching completed still upgrades prior unknown and late unknown remains a no-op. On mismatch, reject or quarantine; freeze ordinary lattice merges; do not store that completed on the reserved record or treat it as durable success for the reserved request.
Why blind prefer-success is unsafe: operation id alone is not identity of the intended request or principal. Concrete corruptions include id reuse or collision settling a different payload as the reserved work; a client that changed inputs after reserve so the late success is for different work; and a stale grant from a prior binding generation applying effects under obsolete credentials. Preferring any completed response authorizes that mismatch.
Ordering: fingerprint and binding generation first, then status merge. Matching success stays monotonic over observer timeout; mismatched success never outranks the reservation or a matching terminal.
Reasoning only; no executed tests; no repository or machine configuration inspected.