Repeated execution of Firebase Realtime Database transaction function causing duplicate writes

Handling Transaction Retries in Firebase

To avoid duplicate writes or side-effects in a Firebase Realtime Database transaction, you must move all non-idempotent logic outside the transaction function. The transaction function should be treated as a pure data transformation that only returns the new value to be written to the database.

Why Duplicates Occur

Firebase uses an optimistic concurrency control mechanism. When the SDK attempts to commit a transaction, it checks if the data has changed since it was last read. If a conflict is detected (another client updated the data), the SDK automatically re-runs the transaction function with the updated data. This process can repeat up to 25 times. Because the SDK does not provide a retry counter or a "commit-only" hook, any code inside the function—such as API calls, analytics events, or local state mutations—will execute every time a retry occurs.

Safe Implementation Pattern

The only reliable way to ensure a side-effect happens exactly once is to trigger it only after the transaction promise resolves successfully.

// ❌ UNSAFE: Side-effect inside the transaction
db.ref('counters/clicks').transaction((currentValue) => {
  sendAnalyticsEvent('clicked'); // This may run 25 times
  return (currentValue || 0) + 1;
});

// ✅ SAFE: Side-effect after successful commit
db.ref('counters/clicks').transaction((currentValue) => {
  return (currentValue || 0) + 1;
}).then((result) => {
  if (result.committed) {
    sendAnalyticsEvent('clicked'); // Runs exactly once upon success
  }
});

Trade-offs of "Exactly-Once" SDK Guarantees

If the SDK were to guarantee exactly-once execution for the function body, it would require a distributed lock or a pessimistic locking mechanism on the server. This would significantly increase latency, reduce throughput for highly contested keys, and potentially lead to deadlocks, contradicting the high-performance, real-time nature of the database.

Verification Steps

• Simulate Conflict: Launch two separate client instances attempting to update the same key simultaneously.
• Instrument Logs: Add a console.log('Transaction Attempt') inside the function. If you see multiple logs for a single successful update, the SDK is retrying.
• Audit Side-Effects: Verify that your external logs or API endpoints receive only one request per successful database update.

Diagnostic Detail Needed: Are you performing side-effects that depend on the specific value calculated during the transaction? If so, you should capture that value from the result.snapshot.val() in the .then() block rather than inside the transaction function.