Repository navigation
cleanup(workout): keep the teardown failure reason on restored recovery - #1330
Conversation
Restored recovery stores and logs the teardown failure reason with the live path, so the next restored attempt still records previousReason. Co-authored-by: Devil <9thLevelSoftware@users.noreply.github.com>
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Verdict: Approve — the restored teardown path now stores and logs the failure reason through the same helpers the live path uses, and the live path's emitted log strings are byte-identical to before. Correctness / Safety FindingsNo correctness or safety findings. Details checked: Ponytail ReviewPonytail: Lean already. Ship. The two new private helpers each have two call sites and remove the duplicated Ponytail net: 0 lines. Suggested Minimal PatchNo patch needed. Final Merge GuidanceCan merge as-is. Files Reviewed (2 files)
Reviewed by minimax-m3 · Input: 74.6K · Output: 24.5K · Cached: 618.4K Review guidance: REVIEW.md from base branch |
Restored teardown recovery now keeps the failure reason.
markRestoredRecoveryRequiredstores theTeardownFailureReasonand logstransition=recovery_requiredthrough the same helper asmarkRecoveryRequired.beginRestoredRecoveryAttemptlogs that stored value aspreviousReason.WorkoutExecutionGuardRestoredRuntimeTestchecks that a rejected owner leaves the stored reason in place, and that the next restored attempt still logs it.Verified with
:shared:compileKotlinIosSimulatorArm64,:shared:compileAndroidHostTest,:androidApp:compileDebugKotlin, and:shared:testAndroidHostTest --tests '*WorkoutExecutionGuardRestoredRuntimeTest*'(-Pskip.supabase.check=true). The restored-runtime suite finished with 12 tests, 0 failures.