[Bug] AAService disables protection after DarkWake filter update failure (HttpClientNetworkError)

[peppolone]

Please answer the following questions for yourself before submitting an issue

• Filters were updated before reproducing an issue
• I checked the knowledge base and found no answer
• I checked to make sure that this issue has not already been filed

AdGuard version

2.19.0.2234 beta (also reproduced on 2.18.0.2089)

Browser version

No response

OS version

macOS 15.7.8 (24G806) Sequoia

Ad Blocking

AdGuard Base filter, EasyList

Privacy

No response

Social

No response

Annoyances

No response

Security

No response

Other

No response

Language-specific

No response

Which DNS server do you use?

Cloudflare DNS

DNS protocol

DNS-over-TLS

Custom DNS

No response

What Stealth Mode options do you have enabled?

Block trackers

Support ticket ID

No response

Issue Details

1. Use AdGuard with Network Extension (System Extension) mode
2. Let the Mac sleep overnight connected to AC power
3. macOS performs a scheduled DarkWake maintenance event (~06:00–07:00)
4. AdGuard attempts automatic filter update during DarkWake
5. Filter update fails with HttpClientNetworkError (network not available during DarkWake)
6. Mac fully wakes up ~28 minutes later
7. Check AdGuard menu bar toggle → protection is OFF

Expected Behavior

A transient HttpClientNetworkError during a DarkWake filter update
should be retried silently at next opportunity with no effect on the
protection state. Protection should remain enabled after wake.

Actual Behavior

After every overnight sleep, AdGuard protection is disabled on wake.
The toggle in the menu bar app is OFF. Confirmed via:
defaults read com.adguard.mac.adguard NetworkFilterEnabled → 0
Requires manual re-enable every morning. Reproduced every night for
several weeks on both v2.18 and v2.19 beta.

Screenshots

Screenshot 1

Additional Information

Exact sequence from Adguard-group.log (June 6 — identical every day):

06:29:41 (Filters) agflm_standard.db: Begin differential update
06:29:41 [NE] AdguardCore DnsChange: DNS servers changed: (null)
^ DarkWake, network offline

06:29:41 ERROR (FiltersService: didUpdateFilters(:)):
AGOuterError: "HttpClientNetworkError: error sending request
for url https://filters.adtidy.org/mac

AdGuard_BugReport.zip

v3/filters.js"

06:29:41 (DnsChangingMonitor) Change DNS fired with: []

--- 28 minutes of silence ---

06:58:02 (DnsChangingMonitor) Change DNS fired with: ["1.1.1.1", ...]
^ Full wake, network restored

06:59:01 (AAService) Setting protection enabled to "NO" ← BUG
06:59:01 (AAService) filteringModuleTouch disabling filtration.
06:59:02 [NE] VPN service emergency stop: XPC connection interrupted
06:59:02 (CoreLibServiceHandler) Service stopped.

KEY OBSERVATION: "Setting protection enabled to NO" fires 30 minutes
after the HttpClientNetworkError, triggered at full wake — not when
the error occurred. This is a deferred state reconciliation bug in
AAService.

SECOND TRIGGER (active use): Same bug triggers during active use.
On June 6 at 18:24, protection turned off 24 seconds after closing
the Preferences window — Mac fully awake. Same AAService →
filteringModuleTouch sequence, triggered by a reconfigFiltering loop
in the NE followed by an XPC connection drop.

What I tried:

• Upgraded v2.18 → v2.19 beta: no effect
• Disabled PowerNap on AC: no effect
• Disabled activateFiltersAutomaticEnabled: no effect

macOS Diagnostic Reports attached.
Reddit thread: https://www.reddit.com/r/Adguard/comments/1tz9jf0

[IaroslavKhvorostenko]

Hello @peppolone

In order to troubleshoot this issue, we need to get your application logs.

Here's what we need you to do:

1. Click AdGuard icon in the menu bar -> Gear -> Advanced -> Logging -> Logging level -> Debug.
2. Reproduce the problem, then remember the exact time it happened.
3. Menu -> Advanced -> Logging -> Export Logs and System Info.….
4. Send this file to qa@adguard.com:
   • include [mac] keyword and ISSUE_NUMBER in the subject of your email
   • specify the exact time when the issue occurred

[peppolone]

Hi @IaroslavKhvorostenko,

I haven't been able to reproduce this bug since applying the WAL workaround described in #1710, so I don't have a fresh occurrence to capture debug logs for.

For context: the last anomalous "Setting protection enabled to NO" in my logs was on June 11, before I switched all three AdGuard databases (agflm_standard.db, adguard.db, agflm_dns.db) to journal_mode=WAL / synchronous=NORMAL. From June 12 onward — about 4 weeks now — there have been zero spurious disabling events, only clean filteringModuleTouch enabling filtration entries.

This strongly suggests #1709 and #1710 share the same root cause: journal_mode=DELETE was leaving agflm_standard.db in a dirty/inconsistent state during DarkWake network failures, which in turn triggered the AAService state reconciliation bug on wake.

One data point that might be useful: a recent AdGuard update reset agflm_dns.db and adguard.db back to DELETE+FULL (the update rewrites the DBs). I had to manually reapply the PRAGMA fix. So far protection hasn't disabled itself again post-update, but I'll keep monitoring since the DarkWake trigger condition is intermittent.

For now, I'd suggest treating #1709 and #1710 as likely duplicates/related — fixing the DB journal mode in AdGuardFLM should resolve both.