fix: App Alerts 'Start Monitoring' no longer freezes the UI during baseline scan#1424
Merged
Merged
Conversation
…seline scan StartMonitoring was a synchronous [RelayCommand] that ran AppAlertService.TakeBaseline() on the UI thread — a walk of Program Files / Program Files (x86) / LocalAppData\Programs plus a full enumeration of both HKLM Uninstall trees (hundreds of subkeys), the same heavy scan RefreshInstalledAppsAsync already offloads with Task.Run. On a machine with many installed apps or a slow disk the window hung for the whole scan. StartMonitoring is now an async command that runs TakeBaseline() + Start() on a background thread and resumes on the UI thread to set IsMonitoring/IsBusy/MonitorStatus. Safe: FileSystemWatcher creation is thread-agnostic and the service's NewAppDetected event is marshaled via the SynchronizationContext captured at construction (verified). Fixes ultra-audit finding P2 #42. Regression tests: StartMonitoring_IsAsync_AndSetsMonitoringState (command is now IAsyncRelayCommand and leaves the VM monitoring after await); existing RefreshInstalledApps_WhileMonitoring test updated to await the now-async command.
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
1 participant
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.
Summary
Fresh ultra-audit finding (viewmodels-A-D, P2), verified against current source.
AppAlertsViewModel.StartMonitoringwas a synchronous[RelayCommand]that calledAppAlertService.TakeBaseline()directly on the UI thread.TakeBaseline()walks Program Files / Program Files (x86) /LocalAppData\Programsand enumerates both HKLMUninstallregistry trees (hundreds of subkeys) — the same heavy scan the tab's ownRefreshInstalledAppsAsyncalready deliberately offloads withTask.Run. On a machine with many installed apps or a slow disk, the window froze for the whole scan.Fix
StartMonitoringis now an async command that runsTakeBaseline()+Start()on a background thread (Task.Run) and resumes on the UI thread to setIsMonitoring/IsBusy/MonitorStatus. The generated command name (StartMonitoringCommand) is unchanged, so the XAML binding still resolves.Safety:
FileSystemWatchercreation is thread-agnostic, and the service'sNewAppDetectedevent is marshaled via theSynchronizationContextcaptured at service construction — so movingStart()off-thread is safe (verified inAppAlertService).Regression tests
StartMonitoring_IsAsync_AndSetsMonitoringState— the command is nowIAsyncRelayCommandand, once awaited, leaves the VM monitoring.RefreshInstalledApps_WhileMonitoring_KeepsBusyInSyncWithMonitoringupdated toawaitthe now-async command (was.Execute(null)fire-and-forget).Checks