Does Realm Offer a Built‑In Retry Wrapper to Prevent Duplicate Writes?

Answer: No built-in retry deduplication

Realm does not expose a built-in retry wrapper that automatically suppresses or deduplicates retried writes. Retry and idempotency logic is the application’s responsibility.

Confirmed facts

• No SDK provides an automatic retry wrapper that collapses duplicate logical writes into a single persisted change. The documented write APIs are realm.write, Realm.executeTransaction, realm.Write, etc., with no built-in deduplication layer.
• All official language bindings honor Realm Core’s ACID guarantee: an exception thrown inside a write transaction rolls back that transaction completely. This holds for Java/Kotlin, Swift, .NET, JavaScript/Node, Go and Flutter bindings when the error surfaces as an exception in the binding.
• Primary-key upserts prevent local duplicate objects. APIs such as insertOrUpdate, copyToRealmOrUpdate, realm.add(obj, UpdatePolicy.ALL) will update an existing object with the same primary key instead of creating a second row.
• Transaction abort guarantees hold for error types that surface as exceptions in the binding: constraint violations, logic errors, I/O errors. Errors that crash the process, e.g., native SIGSEGV or OOM kill, cannot be caught by any binding.

Likely explanation for Sync duplicates

Local state safety does not equal sync history safety. Realm Sync uses operational-transform conflict resolution. A retried write that reaches the server after a transient network error will generate a new operation in the sync history even when the final merged state is identical. Primary-key upserts keep the object state correct locally and on the server, but they do not prevent separate change-set entries.

In offline-first scenarios a write that succeeds locally but fails to sync before app termination will be re-sent on next connect. The server will apply it again; the state remains correct if the primary key already exists, but sync history inflates.

Practical steps for this case

1. Use primary-key upserts for all writes that may be retried. This is the baseline to avoid local duplicate objects.
2. Make writes deterministic and idempotent at the application level:
   • Use client-generated UUIDs as primary keys for new records.
   • Keep the write function pure for a given input; avoid side effects like increment counters inside the transaction.
3. Implement your own retry wrapper around the write call, not inside the transaction. Retry only on transient errors and keep the same logical payload on retry.
4. Verify rollback in your target binding: open a Realm, begin a write, insert an object with a primary key, throw an exception before commit, then query. The object must not exist.

Assumption: you are on a current Realm Core / SDK release where exceptions abort the transaction. Older JavaScript/React Native versions surfaced sync errors via callbacks rather than exceptions; verify the specific binding’s error-propagation model for your version.

One diagnostic detail that changes the recommendation: Are you using Realm Sync with Atlas Device Sync or a local-only Realm? Sync requires application-level idempotency for history size; local-only relies on primary-key upserts and transaction rollback.