Bug
When geo is configured, all interceptors activate synchronously in coreInit() with checkConsent returning false. The geo lookup then runs async (up to 1500ms).
During that window, network calls (fetch/XHR/sendBeacon) matching blockedDomains or known trackers are dropped permanently — the network interceptor has no replay queue (by design, line 20-21 of network-interceptor.js).
Scripts/elements/cookies/storage are queued and replayed on consent — fine. But network beacons are gone forever.
When geo resolves to allow (non-EU visitor), coreAcceptAll() replays queued scripts/elements, but the initial analytics pageview beacon was already dropped. Tracking is silently incomplete.
Root cause
Interceptors install unconditionally before geo resolves. There's no concept of "pending geo, hold but don't drop" for network calls.
Repro
- Configure Zest with
geo + intercept: { network: true } + fallback: 'allow'
- Visit from a non-EU IP
- Network calls during the first ~1500ms are dropped (204 "Blocked by Zest")
- After geo resolves to
allow, new calls fire, but initial beacons are lost
Bug
When
geois configured, all interceptors activate synchronously incoreInit()withcheckConsentreturning false. The geo lookup then runs async (up to 1500ms).During that window, network calls (fetch/XHR/sendBeacon) matching
blockedDomainsor known trackers are dropped permanently — the network interceptor has no replay queue (by design, line 20-21 of network-interceptor.js).Scripts/elements/cookies/storage are queued and replayed on consent — fine. But network beacons are gone forever.
When geo resolves to
allow(non-EU visitor),coreAcceptAll()replays queued scripts/elements, but the initial analytics pageview beacon was already dropped. Tracking is silently incomplete.Root cause
Interceptors install unconditionally before geo resolves. There's no concept of "pending geo, hold but don't drop" for network calls.
Repro
geo+intercept: { network: true }+fallback: 'allow'allow, new calls fire, but initial beacons are lost