FoundationDB Transaction Retry: Server-Side Idempotency Token Absence

Direct Answer

FoundationDB does not provide a server‑side idempotency token mechanism. The cluster does not track, deduplicate, or reject duplicate transaction submissions. Every retry triggered by transaction_too_old (1007) or not_committed (1024) re‑executes the entire transaction function from the start. Applications must implement idempotency themselves—typically by embedding request identifiers in keys, using versionstamped guard keys with conditional writes, or maintaining an external deduplication store.

Confirmed Behavior (FDB 7.x)

• No idempotency_token option exists in fdb_transaction_set_option or any language binding.
• No token tracking occurs in the transaction log, storage servers, or coordinators.
• on_error retry is purely client‑side; the cluster sees each attempt as a new transaction with a new read version.
• Versionstamps are assigned at commit time, not at transaction start, so they cannot serve as pre‑flight deduplication keys.

Why the Design Avoids Server‑Side Tokens

FoundationDB's kernel philosophy treats idempotency as an application‑layer concern, consistent with its lack of secondary indexes, triggers, and stored procedures. Adding server‑side token tracking would require:

1. Consensus on token state across storage servers or a dedicated token log, adding write latency.
2. Partitioning strategy for token keys (hash‑based? range‑based?) that survives rebalancing and recovery.
3. TTL and eviction policy agreed cluster‑wide, with durability guarantees matching the transaction log.
4. Interaction with on_error semantics: a server‑side token must survive client restarts and coordinate with the existing retry loop to avoid double‑apply or lost‑update anomalies.

Stripe‑style idempotency keys assume request‑response semantics (single HTTP call). FoundationDB's interactive transactions—multiple reads and writes before commit—make token scope ambiguous: per‑transaction, per‑session, or per‑client‑defined boundary?

Current Application Patterns (with Trade‑offs)

Pattern	How It Works	Cost
Request ID in key suffix	/request/{uuid}/payload = value	Couples business logic to key layout; sequential UUIDs cause hot partitions
Versionstamp guard key	SET_IF_NOT_PRESENT /idempotency/{token} = versionstamp()	Requires extra read on retry; only prevents duplicate key creation, not re‑execution of other writes unless whole transaction is conditional
External deduplication store	Redis/SQL with SETNX or unique constraint	New failure domain; consistency window between external store and FDB commit

Verification You Can Run

# Submit the same conflicting transaction twice; both commit if the second retry succeeds
fdbcli --exec \"configure single memory; create; open\"
# In a client: run a transaction that writes key A, then immediately retry it with on_error
# Observe: no deduplication occurs; the second attempt commits independently

One Diagnostic Detail That Changes the Recommendation

Are you experiencing actual duplicate side effects (double charges, double emails) in production, or is this a design‑time concern? If duplicates are occurring, the immediate fix is a versionstamp guard key with a conditional transaction; a server‑side token would not ship in any current FDB release.