Skip to content

Windows: suppress settings-triggered VPN notifications#8582

Open
atavism wants to merge 8 commits intomainfrom
atavism/fix-windows-part-two
Open

Windows: suppress settings-triggered VPN notifications#8582
atavism wants to merge 8 commits intomainfrom
atavism/fix-windows-part-two

Conversation

@atavism
Copy link
Contributor

@atavism atavism commented Mar 26, 2026

Resolves

  • Block ads toggle is laggy and triggers an OS-level "Lantern is connected/disconnected" notification on each toggle
  • Routing mode: changes in selection triggers OS-Level "Lantern is connected/disconnected" on each selection

Copilot AI review requested due to automatic review settings March 26, 2026 15:45
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds an “origin” signal to Windows VPN status updates so the app can suppress user-facing connected/disconnected notifications when the VPN is restarted due to settings changes (e.g., Block Ads and routing mode), reducing noisy OS/app notifications during toggles.

Changes:

  • Introduces VPNStatusOrigin on LanternStatus and propagates it through the Windows IPC status stream (with a TTL-based fallback when origin isn’t present in events).
  • Marks Windows status origin as settingsMutation for settings-driven FFI calls, and userAction for connect/disconnect actions.
  • Suppresses connected/disconnected notifications in VpnNotifier when the status origin indicates a settings mutation; adds in-flight guards for routing mode and block-ads setting updates.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
lib/lantern/lantern_windows_service.dart Adds pending/TTL-based origin attribution for Windows status events and includes origin in LanternStatus parsing input.
lib/lantern/lantern_ffi_service.dart Marks Windows status origin for settings mutations and user actions; moves block-ads FFI call into runInBackground.
lib/features/vpn/provider/vpn_notifier.dart Suppresses connect/disconnect notifications when status origin is settingsMutation.
lib/features/home/provider/app_setting_notifier.dart Adds in-flight guards and awaits persistence/service calls for routing mode and block-ads updates.
lib/core/models/lantern_status.dart Adds VPNStatusOrigin enum, parsing logic, and stores origin on LanternStatus.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +73 to +78
if (_isRoutingModeUpdateInFlight) {
appLogger.info(
'Routing mode update already in progress. Ignoring duplicate request.',
);
return right(unit);
}
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The in-flight guard currently ignores any routing mode change request that arrives while a previous update is in progress. If the user quickly switches modes (A→B then B→A), the second request will be dropped and the final persisted/service state may not match the user’s last selection. Consider queuing the latest requested mode (or cancelling/restarting the in-flight request) so the last user intent is always applied, rather than returning success while doing nothing.

Copilot uses AI. Check for mistakes.
Comment on lines +121 to +126
if (_isBlockAdsUpdateInFlight) {
appLogger.info(
'Block ads update already in progress. Ignoring duplicate request.',
);
return;
}
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to routing mode, this in-flight guard drops subsequent block-ads toggle requests while an earlier update is running. If the user toggles quickly (on→off→on), the later intent can be ignored, leaving UI/storage and the core service out of sync with what the user last chose. Consider storing the latest desired value and applying it after the current request completes (or using a debounce/serial queue) instead of returning early.

Copilot uses AI. Check for mistakes.
Comment on lines +146 to +156
static String _originToWireValue(VPNStatusOrigin origin) {
switch (origin) {
case VPNStatusOrigin.userAction:
return 'user_action';
case VPNStatusOrigin.settingsMutation:
return 'settings_mutation';
case VPNStatusOrigin.system:
return 'system';
case VPNStatusOrigin.unknown:
return 'unknown';
}
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wire-value mapping for VPNStatusOrigin is duplicated here and in LanternStatus._originFromJson. This creates a real risk of the two drifting out of sync (e.g., adding a new origin or renaming a wire value). Consider centralizing the conversion in a single place (e.g., extension methods on VPNStatusOrigin for toWire()/fromWire()) and reusing it in both the Windows service and LanternStatus parsing.

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants