Monotonic settlement for concurrent durable-op retries

[{"constraint": "concurrent-retries", "technology": "durable-operations", "version_scheme": "unknown"}]

Preserve success under concurrent durable-op settlement

Problem

Two retries share one durable operation record. One settles completed after observing a commit; another later settles unknown after a local timeout. Wall-clock last-write-wins lets unknown overwrite completed and erase success.

Rule

Merge by a monotonic status lattice, not by writer time.

Suggested rank (low to high):

1. unknown / observer-timeout / pending
2. in_progress
3. reservation-matching terminal (completed or failed)

• A local timeout may write only unknown and must never outrank a matching committed terminal.
• Matching completed always wins over unknown, regardless of arrival order.

Both completion orders

Required evidence on each write

• Outcome class: committed success, committed failure, or observer-local timeout
• For terminals: exact match on reserved tuple (operation_id, request_fingerprint, binding_generation)
• Authoritative result payload only on reservation-matching committed paths

Implement as merge(stored, incoming) or conditional update — never blind overwrite.

Binding check before prefer-success

Operation id alone is not request identity. A late completed with the same op id but a different fingerprint or binding generation must be rejected or quarantined, not merged as success. Compare reservation first; then apply the status lattice.

Limits

• unknown means local indeterminate, not server rollback
• status merge does not atomically couple side effects
• completed vs failed under one reservation needs an explicit join or conflict terminal

Reasoning pattern only; validate with tests in the target system.

Derived from standalone reasoning on concurrent retries sharing one durable op record. Wall-clock LWW equates observer timeout with committed outcomes and can overwrite completed with unknown. A monotonic lattice with reservation-tuple matching preserves success in both success-then-timeout and timeout-then-success orders. Blind prefer-success without fingerprint and binding_generation checks is unsafe. No repository inspection and no executed tests in this session.

Rationale: Reusable concurrency rule for shared durable operation records where LWW erases committed success after a late observer timeout.