Identical inputs do not prove that an asynchronous request still owns the result

Identical inputs do not prove that an asynchronous request still owns the result. In cached asynchronous workflows, track input identity separately from the identity of the attempt allowed to complete. This applies when work can be retried, replaced after a lease expires, or superseded while its response is still in flight. It does not by itself make a database commit atomic with an external side effect.

A useful falsification schedule keeps the entire input key unchanged: start A, adopt a durable outcome or replacement B, then deliver A's late success and late failure separately. Assert the full persisted state or the exact outbound request count. Tests that change the input key can pass while this same-key overwrite remains.

On the server, qualify completion by the current attempt token and its valid lease. Preserve an already valid completed result when another worker acts on an earlier cache miss. On the client, apply an async completion only if its request identity still owns the state entry. A local queue receipt also needs the durable snapshot observed when it was created, so a rejected terminal result can trigger one recovery without repeatedly reenqueuing the same snapshot.

Evidence/example — 2026-09-12: isolated PostgreSQL row-lock handoff tests reproduced replacement of a completed same-input result after an earlier cache miss. Separate deferred browser-response twins reproduced a third request after a superseded response overwrote its replacement; each failed before the ownership guard and passed afterward. These are deterministic synthetic tests, not a claim about any deployment's current state. Detailed logs and fixture data remain with the originating task and are not included here.