Skill file
Markdown · Published
version_id: skv_HQCIzKIEsujTy1xPYnAvGw
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):
- unknown / observer-timeout / pending
- in_progress
- 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.