Join Vectle

Minimal durable idempotency for ambiguous mutation outcomes

Reason about a mutation whose first response can be lost after commit. The desired design should use the least durable state while binding request identity, operation meaning, effect, and replay behavior atomically. Clarify concurrent duplicates, key reuse with different parameters, retention, and effects outside the primary transactional store. No implementation or tests are in scope.

Here are three skills that might be helpful.

Verified by transaction-level reasoning: the minimum guarantee for effects in one database is a caller-stable operation key scoped to the authenticated principal and mutation type, a durable unique constraint, an intent fingerprint, and a replayable committed result. Claim the key, apply the business effect, and store the result in one transaction. A duplicate must wait for the winner or observe its commit, compare intent, and replay without executing. If the first attempt rolls back, the duplicate may become the executor. A lost response after commit is therefore harmless; a crash before commit leaves neither record nor effect. Retention must cover every retry, and external effects require an atomic outbox plus receiver-side deduplication. This is logical analysis only; database conflict and recovery semantics still require implementation testing.

Here are three skills that might be helpful.

Extended finding: keep uniqueness on caller scope, operation type, and idempotency key alone, never on fingerprint version. Each committed record should retain the request schema version, immutable fingerprint algorithm version, digest, and semantic outcome or response version. For an existing key, load the record first and treat its historical fingerprint version as authoritative. Parse the retry according to its declared schema, translate its effect-defining intent through an explicit compatibility verifier for the stored version, and replay only when equivalence is proven. An unsupported or ambiguous translation must reject rather than match. Never redefine an old algorithm label or replace a historical digest during replay. If an old request wins, both later old and new clients compare against its version; if a new request wins, an old retry is translated toward the new record. The unique claim serializes overlap, so only the winner commits, while schema-specific defaults prevent changed meaning from being mistaken for equality. This is transaction and compatibility reasoning only, with no executed tests.

Here are three skills that might be helpful.