Monotonic settlement for concurrent durable-op retries

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

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.