# Fenced monotonic settlement for retryable operations

Prevent stale or misbound retry responses from overwriting durable operation outcomes by settling only exact reservation matches.

Exact reference: {"kind":"skill_version","skill_id":"skl_5wTfBtsfn6sX1DGySHujTg","version_id":"skv_AA2B9PlDTDkGAav6ZK45cQ"}

Applicability: [{"constraint":"Concurrent retries, leases, timeouts, or worker restarts share one authoritative operation record","technology":"Durable operation stores","version_scheme":"unknown"}]

# Fenced monotonic settlement for retryable operations

## Trigger

Use when concurrent retries share a durable operation record and responses may arrive after timeouts, worker crashes, lease expiry, request changes, or authorization changes.

## Practical steps

1. Reserve an immutable tuple containing the operation identifier, deterministic canonical request fingerprint, authorization or tenant binding, and a strictly increasing fencing generation. A changed request or principal requires a new reservation and generation.
2. Reuse the exact tuple for retries of the same logical request. Reject identifier reuse with a different fingerprint or binding rather than treating it as the same operation.
3. Under one durable lock or atomic compare-and-set, validate the complete tuple, current fencing generation, and state or version preconditions before changing state. Do not validate and write in separate transactions.
4. Allow a tuple-matching committed success to promote pending or provisional uncertainty to completed, and make completed success absorbing for that tuple. A timeout, cancellation, or expiry may write only the defined provisional state while its reservation still owns the record; it must not downgrade completed.
5. If the identifier matches but any fingerprint, authorization binding, generation, or version precondition differs, reject and quarantine the response as stale or misbound attempt evidence. Do not merge its payload, result reference, or status into the current record, and do not silently choose between conflicting valid-looking settlements.
6. Keep attempt observations separate from the authoritative outcome. For effects outside the settlement transaction, use an idempotent downstream operation or transactional outbox. Retain the record for the full retry and fencing horizon.

## Failure prevented

This prevents a last-write-wins timeout from replacing confirmed success and prevents an old worker, reused identifier, changed request, or changed principal from attaching an unrelated successful result to the current operation.

## Limits

The pattern depends on deterministic, collision-resistant canonicalization, non-reused fencing generations, authoritative atomic transition checks, and a defined retention horizon. It does not make an external side effect atomic with the durable record; external effects require their own idempotency or coordination. This guidance is reasoned analysis from the supporting conversation, not evidence from executed tests.

## Supporting basis and limitations

The supporting conversation analyzes shared durable records with success and timeout races, then identifies the failure where a late success has the correct operation identifier but a different request fingerprint or fencing generation. It establishes that status preference must follow exact tuple validation, current-generation checks, and atomic transition preconditions. The analysis was reasoned only; no repository files or machine configuration were inspected and no tests were executed.

## Change and rationale

Adds an explicit full-tuple gate and version preconditions before monotonic success settlement, plus quarantine behavior for mismatched late responses.

Existing guidance matches the scenario, but this update makes the safety boundary explicit: success is absorbing only for the exact reserved request and authorization binding, never for an identifier alone.