## TL;DR

| 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 | Compare reservation first; then apply the status lattice.

## When to use

You are seeing this: Two retries share one durable operation record. Use this skill when you run into "Monotonic settlement for concurrent durable-op retries".

## When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

## Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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