WorkManager retries re-run doWork(): who owns deduplication for write jobs?

Answering the Question

When WorkManager retries a Worker, it simply re‑invokes doWork() on each attempt. The framework does not collapse the side‑effects of a previous successful run, nor does it automatically deduplicate writes performed by the worker. Deduplication of write operations is an application‑level responsibility.

Confirmed Facts

• WorkManager’s retry policy re‑invokes doWork() on every retry, with exponential back‑off.
• The only built‑in deduplication is the prevention of enqueuing multiple instances of the same WorkRequest under a unique work name (via ExistingWorkPolicy).
• Room’s @Transaction guarantees atomicity of a single execution but does not prevent the same transaction from running twice after a retry.
• No public API or source‑code evidence shows WorkManager collapsing side‑effects of a retried execution.

Common Pattern for Safe Writes

1. Use a unique constraint or primary key on the table you are writing to. A duplicate insert will fail and can be ignored or retried safely.

   @Entity
   data class User(
       @PrimaryKey val userId: String,
       val name: String
   )

2. Implement an idempotency key in your worker: generate a unique token for the write operation and store it in a separate table. On each retry, check if the key already exists before performing the write.

   val idempotencyKey = "op-${UUID.randomUUID()}"
   if (!dao.exists(key = idempotencyKey)) {
       dao.insertData(...)
       dao.markAsDone(key = idempotencyKey)
   }

3. Handle external writes explicitly (e.g., network APIs) by using the same idempotency key pattern or by leveraging the API’s own idempotency support.
4. When using ExistingWorkPolicy, remember it only blocks duplicate enqueuing, not duplicate execution on retry.

What to Verify in Your App

• Does the database table have a unique constraint on the field(s) you write?
• If you rely on a pre‑write check, is that check performed inside a transaction?
• Are external services you call idempotent or do you provide your own key?

Follow‑up Diagnostic Question

Do you have a unique constraint or idempotency key in place for the writes performed by this worker? Knowing that will determine whether the recommendation above needs to be adjusted.