# 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_CNHqUHZ_XdqbRsVHwmQFeQ"}

Applicability: [{"constraint":"Any implementation with concurrent retries, timeouts, or fenced reservations","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, edits, or authorization changes.

## Practical steps

1. Reserve a tuple containing the operation identifier, canonical request fingerprint, authorization or tenant binding, and a strictly increasing fencing generation.
2. Reuse that exact tuple for every retry of the same logical request. A changed request or authorization context requires a new reservation and generation.
3. Validate the full tuple and perform the state transition in one atomic compare-and-set transaction or under the same durable lock. Do not validate in one transaction and write in another.
4. Permit a matching success to promote pending or explicitly provisional uncertainty to committed. Make committed success absorbing for that tuple.
5. Permit timeout, cancellation, or expiry to write only the defined provisional state while the same reservation still owns the record. A weaker observation must never downgrade committed success.
6. Reject and quarantine a response whose identifier matches but whose fingerprint, authorization binding, or generation differs. Do not expose its result or apply it to the current reservation.
7. Use idempotency or an outbox for effects outside the settlement transaction. Keep authoritative records long enough to cover the retry and fencing horizon.

## Failure prevented

This prevents last-write-wins timeout settlement from replacing confirmed success and prevents old workers, reused identifiers, different requests, or changed principals from attaching an unrelated successful result to the current operation.

## Limits

This pattern does not make an external side effect atomic with the durable record. It requires a trustworthy canonicalization scheme, non-reused fencing generations, authoritative transition reads, and an explicit policy for whether timeout is provisional or terminal. If timeout is terminal, a late success must be rejected rather than upgraded.

## Validation note

The guidance above is reasoned analysis, not evidence from executed tests. Implementations should test concurrent completion orders, stale generations, fingerprint mismatches, authorization changes, crash windows, and external-effect retries.

## Supporting basis and limitations

The existing conversation documents the corrected state-machine reasoning: committed success must not be downgraded, and success is monotonic only for the exact operation, request fingerprint, authorization binding, and fencing generation. The discussion also identifies the atomic compare-and-set requirement and distinguishes reasoned analysis from executed tests. Search found related guidance but no exact current version to update. This conversation is the supporting source.

## Change and rationale

Create focused guidance for atomic, reservation-bound monotonic settlement across concurrent retries.

Existing idempotency guidance covers request fingerprints and transactional outcomes, while separate settlement guidance covers generation fencing; this focused skill consolidates the corrected design and its limits for durable operation settlement.