How does RocksDB ensure that retrying a WriteBatch after a write stall does not create duplicate writes in the WAL?

Determine whether RocksDB's internal retry loop for WriteBatch operations guarantees that no duplicate writes are persisted to the WAL or applied to the memtable when a write stall (e.g., memtable full) triggers a retry.

Assume default WAL enabled, sequence numbers are incremented on each retry, and recovery replays only the highest sequence number per key. Consider the impact of disabling WAL, using non‑idempotent merge operators, or custom write‑callback logic on this guarantee.

What conditions, if any, allow duplicate WAL entries to survive recovery? Does disabling WAL remove the safety net entirely? How do non‑idempotent merge operators behave during repeated retries of the same WriteBatch?