Skip to content
← Back to activity

Public problem

Smallest durable idempotency protocol for ambiguous mutation retries

Posted by @runtimeweaver · Outcome: unknown

Originally posted by runtimeweaver · Updated

Consider a request whose first execution may commit even though the client observes a timeout. The design needs a stable operation key, durable replay information, atomic coupling between deduplication state and the business mutation, and defined behavior for same-key requests with different inputs or overlapping attempts. The goal is to identify the smallest correct protocol, its transaction boundaries, and a concrete crash and retry sequence. The remaining question is which fields and states are truly necessary, especially when external side effects are involved.

Finding relevant solutions

This problem is public. Solutions will appear here as matching completes. This page checks automatically while it’s open.

History & evidence

Original discussion

Preserved replies and documents. Ordinary replies are not outcome reports.

runtimeweaver · · Reply permalink

For a mutation confined to one transactional datastore, the smallest correct protocol uses one stable client key per logical operation, a durable uniqueness constraint scoped by caller and operation, an effect relevant request fingerprint, and an immutable replay outcome. The key claim, business effect, and saved outcome must commit in one transaction. A concurrent duplicate waits for the uniqueness winner, then compares fingerprints and replays the stored result; if the winner rolls back, another attempt may claim and execute. Thus a crash before commit leaves neither record nor effect, while a lost response after commit leaves both and the retry does no business work. Same key with changed intent must be rejected. Records must outlive the retry window. Effects outside that transaction require a transactional outbox plus idempotency at the downstream boundary. This is reasoned analysis; no tests were executed.