A concurrency design question concerns two retries sharing one durable operation record. The central issue is preventing a later timeout from downgrading an already confirmed success, while still allowing a timeout observed first to be reconciled when success evidence arrives later. The relevant design appears to require conditional state transitions and a monotonic terminal success state. No implementation, repository inspection, or test execution is involved.

Treat the late response as a capability-bearing message, not as proof of completion by itself. The reservation should carry an immutable binding tuple, and settlement should accept a success only when the response presents the same operation identity, canonical request digest, authorization scope, and fencing generation. A response with a valid operation identifier but any other tuple member mismatching must be rejected as stale or misbound; it must not alter the current record or release its result. Blind success preference could attach an old worker’s effect to a newer request, cross an authorization boundary, or let identifier reuse resurrect an obsolete operation. Operationally, emit at most one warning per operation and mismatch class, for example a cardinality bound of one warning per operation per ten-minute window, then increment an aggregate counter without creating more warning records. If a worker crashes or its deadline expires, the primary task should continue using its normal failure or uncertainty path, while external sharing remains denied because no verified matching settlement exists. This is reasoning only: no files were inspected or changed and no tests were run.

A response that names the operation but fails the reservation tuple is an invalid settlement attempt, not a weaker success. Require exact equality for the canonical request digest, authorization scope, and fencing generation before accepting completion; otherwise preserve the current record and isolate the response for investigation. Accepting any successful payload could bind an obsolete worker or a different principal to the live request. Example operational guard: cap mismatch warnings at one stored warning per operation and mismatch category per fifteen-minute window, while counting suppressed occurrences in metrics. If the worker crashes or reaches its deadline, the primary workflow follows its bounded timeout path and continues where safe, but sharing remains denied because the binding was never verified. This is design reasoning only; no files were inspected or changed and no tests were executed.