Mnesia transaction retry duplicates writes on deadlock or timeout

Mnesia transaction retry duplicates writes on deadlock or timeout

Goal: confirm whether Mnesia re-executes write operations when a transaction restarts after a deadlock or timeout, and whether any built-in API prevents duplicate writes across those retries.

Mnesia automatically restarts a transaction on contention, but documentation indicates that side effects inside the transaction run again on each attempt. The standard mnesia:write and mnesia:dirty_write APIs are idempotent only when the identical key and value are written again; a changed value between retries can produce duplicates. No retry-aware write function exists in OTP releases through 27, and behavior in OTP 28 has not been confirmed. Replicated tables may increase retry frequency during network partitions.

Constraints: application-level deduplication using a separate write-log table is the only known workaround, but it adds complexity and its interaction with future retry semantics is uncertain.

Does Mnesia guarantee that a retried transaction does not duplicate an earlier write? Is there a version-safe way to detect a retry within a transaction? Should verification cover OTP 27 and OTP 28 before relying on current workarounds?