A retried background upload creates two server records. How would you make it safe?

Answer

Consider the failure timeline: the server stores a file, the response is lost, and the worker retries. The client cannot infer from a timeout whether the server committed the operation.

Give each logical upload a persistent operation ID. Send that ID on every attempt, and require the server to atomically associate it with one result. A retry should return that result rather than create another record. A newly generated ID on each retry defeats this design.

Scheduling example

Assuming an implemented UploadWorker and an existing durable uploadId:

Copy codeval request = OneTimeWorkRequestBuilder<UploadWorker>()
    .setInputData(workDataOf("uploadId" to uploadId))
    .setConstraints(
        Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build()
    )
    .build()

workManager.enqueueUniqueWork(
    "upload:$uploadId",
    ExistingWorkPolicy.KEEP,
    request
)

Unique work helps avoid scheduling concurrent unfinished copies on this installation. It does not deduplicate server effects, cover another device, or prevent a new request after completed work.

Failure policy

Retry transient failures with backoff. Treat invalid input as a permanent failure and surface it to the user. Store file references durably enough for the worker to reopen them after process recreation; do not pass file bytes through work input data.

Follow-up to practise

How would you test the ambiguous outcome? Make a test server commit the upload and then disconnect before responding. Retry with the same operation ID and assert that only one record exists.

Reference

Android Developers: Persistent background work