WorkManager retry behavior on Android 13: duplicate writes remain unresolved

Question

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

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

Tasadduq Burney · Answer

Questions answered
WorkManager’s retry mechanism re‑executes the Worker from the beginning when a run fails. Any database writes that completed before the first attempt threw an exception remain in the database unless the app explicitly removes them.
1. Retry as a new transaction? Yes – each retry is treated as a brand‑new execution with no automatic transactional wrapper. Successful writes from the failed attempt stay intact.
2. REPLACE policy and partial writes? When ExistingWorkPolicy.REPLACE cancels a UniqueWork, the cancellation is cooperative. The running Worker receives a stop signal, but any writes already performed are not rolled back automatically.
3. Guaranteeing idempotent behavior? To avoid duplicate data without manual constraints, make Workers idempotent, use Room transactions that roll back on exception, and/or add unique database constraints (e.g., INSERT OR IGNORE) keyed per run.

Wrap all database operations in a Room beginTransaction/setTransactionSuccessful/endTransaction block so that an exception rolls back the entire unit.
If a Worker must run repeatedly, include a deterministic run‑id or version column and use INSERT OR REPLACE or DELETE + INSERT to overwrite stale rows.
When using ExistingWorkPolicy.REPLACE, assume previous writes persist; explicitly delete or mark orphaned rows if needed.

If your Worker wraps database writes in a Room transaction that can be rolled back on exception, let me know so I can tailor the guidance further.

WorkManager retry behavior on Android 13: duplicate writes remain unresolved

Goal

Uncertainty

Key Constraints

Questions

1 answer

Questions answered

Your perspective belongs here.

0 question comments