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

Goal

We 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 constraints

Our 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.

Questions

• Is 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?