fix(cli): stop daemon before reset and show progress screen (#1494)#1514
Merged
Aaronontheweb merged 3 commits intoJun 29, 2026
Merged
Conversation
…dev#1494) On Windows, `netclaw init` → Full reset fails because the daemon holds the log file handle open, and `Directory.Delete(path, recursive: true)` bails on the first locked file. Fix: - Inject `DaemonManager` into `InitExistingInstallViewModel` and call `StopAsync('factory-reset')` before any deletions to release file handles. Stop is best-effort — if the daemon isn't running or is externally managed (Docker container supervisor), it's silently ignored. - Show a progress screen with staggered checkmarks so the operator sees what's happening: daemon stop → data deletion → purge complete, with a spinning dots glyph on the current step and green checkmarks for completed steps. After completion the wizard auto-launches. Test updates: - Added FakeSupervisor to InitExistingInstallViewModelTests to satisfy the new DaemonManager constructor parameter (matching HealthCheckStepViewModelTests pattern).
Aaronontheweb
added a commit
that referenced
this pull request
Jun 30, 2026
… host crash (#1525) #1494/#1514 moved the install reset onto a background Task.Run thread that publishes progress by writing four ReactiveProperty instances (StatusMessage, CurrentProgressStep, ProgressMessage, CanQuitProgress). In production those writes marshal onto the single Termina render-loop thread, but an unbound view model (unit tests) runs them inline on the background thread while the test thread subscribes/disposes the same property. R3's ReactiveProperty is not thread-safe: its value-set walks the observer linked list lock-free while Subscribe/Dispose mutate that list under a lock, so the two race and can corrupt the list into a cycle -> infinite loop -> the reset Task never completes and the xunit host is killed by the watchdog (flaky 'Test host process crashed', no stack trace, Ubuntu-only; the same commit was seen both green and red). R3's documented remedy for shared state written from multiple threads is SynchronizedReactiveProperty, which serializes set/subscribe/dispose on one monitor (uncontended in production). The declared type stays ReactiveProperty<T> so the page and all readers are unchanged. Fixes flaky InitExistingInstallViewModelTests.ResetFailure_ShowsErrorAndDoesNotNavigate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On Windows,
netclaw init→ Full reset fails with:The daemon
netclawdholds the log file handle open, andDirectory.Delete(path, recursive: true)aborts on the first locked file. The operator gets stuck on a confirmation screen with no way forward.Fix
1. Stop the daemon before deletion
Inject
DaemonManagerintoInitExistingInstallViewModeland callStopAsync('factory-reset')before anyDirectory.Delete()calls. This releases the file handles so Windows lets the deletion proceed.Stop is best-effort — if the daemon isn't running or is externally managed (Docker container supervisor), it's silently ignored.
2. Show a progress screen with staggered checkmarks
Instead of confirming → instant failure, the operator now sees a dedicated progress screen:
Each step fades in as it completes — the current step gets a spinning dots glyph, completed steps get a green checkmark, pending steps are dimmed. After purge completes there's a brief 600ms pause so the user sees the ✓, then the wizard launches automatically.
Key properties:
StopAsyncthrows (not running, external supervisor), the delete still proceeds.Files changed
src/Netclaw.Cli/Tui/InitExistingInstallViewModel.cs— AddedDaemonManagerdependency,Progressphase,RunResetAsync()lifecycle, and progress-state propertiessrc/Netclaw.Cli/Tui/InitExistingInstallPage.cs— AddedBuildProgressScreen()with staggered checkmarks and spinner, updated key bindings for progress phasesrc/Netclaw.Cli.Tests/Tui/InitExistingInstallViewModelTests.cs— AddedFakeSupervisorinner class and wired it into theCreate()factory to satisfy the new constructor signature