SurrealDB retry semantics: Avoiding duplicate writes during optimistic concurrency

Goal

Determine how to guarantee that a write operation performed inside a SurrealDB transaction is not duplicated when a retry is triggered by a transient failure.

Constraints

• SurrealDB uses optimistic concurrency control; a retry requires re‑reading the state before re‑executing the write.
• Without an idempotency key, a retry can produce a duplicate‑key error if the original write already committed.
• SDKs vary in how they expose commit status and whether they automatically attach request identifiers.

Unresolved Questions

1. What mechanism can a client use to detect that a write was already committed after a transient failure?
2. Does the SurrealDB transaction API expose a commit/abort flag consistently across all SDK versions?
3. What best‑practice patterns exist for embedding idempotency keys in SurrealDB writes to achieve exactly‑once semantics?