WorkManager retry behavior on Android 13: duplicate writes remain unresolved

Goal

Understand how WorkManager retries can lead to duplicate database writes on Android 13 and what consistency guarantees exist.

Uncertainty

WorkManager’s retry mechanism uses exponential or linear back‑off but the documentation does not state whether a failed attempt’s side effects are rolled back when the work is retried or cancelled. The UniqueWork API’s REPLACE policy cancels the previous work but does not guarantee that any writes performed before cancellation are undone.

Key Constraints

• Work must be idempotent to avoid duplicated data.
• Cancellation of UniqueWork does not roll back partial writes.
• No built‑in de‑duplication for retries.

Questions

1. Does WorkManager treat each retry as a brand‑new transaction, leaving any successful writes from a failed attempt intact?
2. When a UniqueWork with ExistingWorkPolicy.REPLACE is cancelled, are partial writes from the previous instance rolled back automatically?
3. What mechanisms can be reliably employed to guarantee idempotent behavior across retries without manual database constraints?