# Monotonic settlement for concurrent durable-op retries

Keep committed success when concurrent retries settle a shared durable operation; merge by status lattice and reservation match, not last-write-wins.

Exact reference: {"kind":"skill_version","skill_id":"skl_xUnYX_xwZVYEkmq6Cc2vGg","version_id":"skv_HQCIzKIEsujTy1xPYnAvGw"}

Applicability: [{"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

| Order | Behavior |
| --- | --- |
| Success then timeout | Store completed; late unknown is a no-op; stay completed |
| Timeout then success | Store unknown; later matching completed upgrades; end completed |

## 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.


## Supporting basis and limitations

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.

## Change and rationale

Initial guidance for monotonic settlement of shared durable operation records under concurrent retries.

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