Switching FaunaDB writes to server-side idempotency keys: what changes for existing retry logic?

Question

GoalWe are moving our FaunaDB write path from manual client-side retry loops to driver-level retries combined with conditional FQL writes, and we need to prevent duplicate documents when a commit succeeds but the response is lost.Context and constraintsOur collections are written from multiple regions, so we cannot rely on client-side timestamps for deduplication due to clock drift. Fauna's transaction model provides strict serializability, and the drivers resubmit transactions on transient conflicts or timeouts. We are considering wrapping each create in an FQL if expression that checks for an existing record with the same natural key before inserting.The open question is how this interacts with the driver's automatic retry behavior: whether a retried transaction carrying the same conditional check is guaranteed to be a no-op, and whether there is any visibility window across regions where the existence check could pass twice during a partition or high-latency event.QuestionsIs a conditional if existence check inside a single transaction sufficient to make driver retries safe against duplicates, or is an explicit idempotency key field with a unique index required?Under a cross-region partition, can a committed write be invisible to a retry's existence check long enough to allow a duplicate?Does the Fauna driver expose a way to distinguish "committed but response lost" from "never committed" after a timeout?

Tasadduq Burney · Answer

AnswerSwitching to a server‑side idempotency check (an if expression that tests for an existing record with the same natural key before inserting) makes the existing Fauna driver retry logic safe; you do not need to change the retry configuration.Confirmed factsThe conditional check and the Create are executed in a single Fauna transaction, so the read of the index and the write are atomic. A driver retry of the same transaction will see the already‑committed record and take the else branch, producing no duplicate.Fauna provides strict serializability (Calvin ordering). After a transaction commits, any later transaction—including a retry issued after a timeout—will observe the committed document; there is no cross‑region visibility window where the write is invisible.The Fauna driver does not expose a way to distinguish “committed but response lost” from “never committed” after a network timeout; both appear as a transient error that triggers a retry.Likely explanation / practical stepsKeep the existence check and the Create inside the same FQL query (e.g., if(Exists(Match(Index('by_natural_key'), key)), Get(...), Create(...))).Leave driver retries enabled for transient errors (conflicts, timeouts). The retried transaction will be idempotent because of the conditional guard.Add a unique index on the natural key as a hard backstop; it will reject any concurrent write that somehow passes the check, turning a potential duplicate into a retryable conflict error.Verify that the driver’s retry policy only includes transient error classes (e.g., FaunaError with isRetryable true). If it retries non‑idempotent errors, adjust the policy.Missing diagnostic detailPlease confirm which error types the driver is configured to retry (e.g., only transient conflicts/timeouts). If the driver retries non‑idempotent errors, the conditional guard alone may not be sufficient and you would need to narrow the retry list.

Switching FaunaDB writes to server-side idempotency keys: what changes for existing retry logic?

Goal

Context and constraints

Questions

1 answer

Answer

Confirmed facts

Likely explanation / practical steps

Missing diagnostic detail

Your perspective belongs here.

0 question comments