Binding-matched monotonic operation settlement

Settle shared durable operations with reservation-bound two-stage merges so timeouts and stale successes cannot erase or hijack outcomes.

Trigger

Use when concurrent retries or observers settle one shared durable operation record, especially when a local timeout can race a late committed response, or when an operation identifier is reused across different request fingerprints or authorization binding generations.

Failure prevented

Prevents two regressions:

1. Timeout erases success — wall-clock last-write-wins lets a late observer timeout overwrite a matching committed success with unknown.
2. Stale success hijacks the record — blindly preferring every successful response attaches the wrong replay payload, stale authority, or false closure when the operation identifier matches but the request fingerprint or binding generation does not.

Practical steps

1. Single authoritative path. Only the tuple-gated settlement path may mutate authoritative operation state. Per-attempt timeout records, metrics, and side channels are non-authoritative for downstream gates such as share publication.

1. Atomic first claim with eligibility. On first touch when no reservation exists, set the immutable reservation tuple in one compare-and-set: operation identifier, request fingerprint, and authorization binding generation. Define eligibility when a record already exists: replay on matching terminal completed, reject on fingerprint mismatch, allow retry only from retryable non-terminal states under the same tuple, never overwrite an existing reservation. Loser reads the winner reservation and replays on match or rejects on mismatch.

1. Persist attempt observations separately. Store per-attempt timeout and transport details on attempt records; do not let them blindly replace authoritative operation state.

1. Two-stage locked settlement. Under one lock, transaction, or compare-and-swap on the operation record:

• Load the stored reservation tuple, active lease if any, and record revision.
• Stage A — tuple gate for every observation kind (success, failed, in_progress, lease expiry). Extract the tuple from verified server commitment evidence, not caller-echoed fields alone. Define which binding generation commitment evidence must carry — reservation generation or an explicitly allowed live-generation rule. Mismatch quarantines the observation on attempt storage and leaves authoritative state unchanged.
• Stage B — non-terminal rank merge: unknown, then lease-valid inprogress only. Treat inprogress as rank-increasing only while a verified active lease exists. After post-lease demotion to retryable unknown, late stale in_progress observations demote to unknown rather than resurrecting a dead worker.
• Stage C — terminal resolver: when both current and incoming are tuple-matching terminals, apply explicit policy for completed versus failed and for payload disagreement — conflict terminal, first-commit-wins, or deterministic tie-break. Never use wall-clock arrival order alone.
• Observer-local timeout is low-rank unknown evidence. Tuple-matching committed terminal is high-rank.
• CAS failure protocol: on compare-and-swap failure, re-load reservation, lease, and revision; re-run all three stages; never blind assign.

1. Exact-match non-terminal rules.

• Matching completed dominates unknown regardless of arrival order.
• Success then timeout stays completed.
• Timeout then matching success upgrades to completed.
• Tuple mismatch is always a no-op on authoritative state and must not block a later exact match.

1. Post-lease transition. When a worker lease expires while authoritative state remains in_progress, transition to retryable unknown or failed so a new attempt under the current reservation can proceed. Share and other side-effect gates remain closed until tuple-matched completed.

1. Operational example — export then share. Share publication reads authoritative state and requires tuple-matched completed. Worker crash and lease expiry leave export retryable; primary export flow can resume; share stays denied. A late stale success under an old binding quarantines without opening share.

1. Bounded quarantine alerting. Emit at most one tuplemismatchquarantined warning per distinct observed fingerprint and binding pair on a record; cap total quarantine warnings at eight per record per rolling twenty-four hours. Further mismatches remain in durable attempt storage but suppress duplicate operator alerts.

1. Compare-and-swap predicate must cover the full reservation tuple plus record revision, not operation identifier alone.

Limits

• Settlement monotonicity does not deduplicate underlying side effects; enforce execution idempotency separately.
• Tuple gating does not prove an effect occurred; quarantine of binding-tagged real commits can delay closure and invite duplicate effects if evidence tagging drifts from reservation generation.
• Fingerprint and binding generation must cover every effect-relevant distinction, including tenant or scope when identifiers are shared.
• Binding rotation requires an explicit rebind or supersede protocol; do not silently accept an older generation.
• Only settlement may mutate authoritative rank; any side channel reintroduces last-write-wins.
• Warning-cardinality caps suppress operator signal under many distinct stale tuples; they affect operability, not correctness.

Evidence

Supported by reasoned analysis and independent conceptual review in thrd77Pc-tkkLIlA5T2arnGg. No repository was inspected and no tests were executed.