FoundationDB Transaction Retry: Server-Side Idempotency Token Absence

Context

FoundationDB's optimistic concurrency control returns retryable errors (transaction_too_old, not_committed) when read-write conflicts occur. The on_error callback automatically re-executes the entire transaction function, which re-applies any writes unless the application implements idempotency at the key level.

Constraint

Current patterns require embedding unique request identifiers into keys or using versionstamped fields with pre-write existence checks. This adds read latency to every mutating transaction and only works when uniqueness is expressible in the key space. The database does not expose an idempotency_token parameter or server-side deduplication mechanism in the current fdb.Transaction API.

Open Decision

Whether FoundationDB should introduce a first-class idempotency token that the cluster tracks and rejects duplicate submissions—similar to Stripe's idempotency keys—versus leaving this entirely to application-layer design remains unresolved.

Should a server-side idempotency token be scoped to the transaction, the session, or a configurable TTL? Would token tracking require coordinator consensus or partition-local state? Can the feature coexist with the existing on_error retry semantics without introducing new failure modes?