From 40c8ee6eb0564172f49c36fbdace6b0106315ef6 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 27 Oct 2026 21:34:10 +0600 Subject: [PATCH] [2026-10-27] eagle: work/projects/cpm-post-release-analysis-2026-10-27.md --- .../cpm-post-release-analysis-2026-10-27.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/work/projects/cpm-post-release-analysis-2026-10-27.md b/work/projects/cpm-post-release-analysis-2026-10-27.md index 60d526d6..ae0e9a6e 100644 --- a/work/projects/cpm-post-release-analysis-2026-10-27.md +++ b/work/projects/cpm-post-release-analysis-2026-10-27.md @@ -212,3 +212,22 @@ Telemetry: every confirmed permanent hang (iOS 0.30%, macOS 2.07% of DAU) had th **Reinterpretation:** "idle wake" is a *state at failure*, not proven to be a cause. On desktop the background unloads after every 30 s idle, so a large share of all navigations, healthy ones included, run right after a wake, and failures from any cause land in this group at that base rate. That fits P1 changing nothing. Confirming it needs a healthy-navigation baseline (background state on successful measurements); none exists since #7384 was closed. Remaining untested production ingredients: the real macOS `Tab` stack (DDG user scripts / content-blocking rule lists in tabs, multiple windows, pinned and hidden tabs, App Nap); needs the app-hosted harness in a VM. + +## Plan and corrections (27 Oct) + +### Corrections +- **P6 is not the feature flag.** `webExtensions` is on in production, not toggled, and will be removed. The flag-cycle mechanism (also in the `tabControllerMatchesContext` doc comment) was an old unverified hypothesis. Established: a tab's web view gets the controller only at creation and only if `webExtensionManager` exists then (`WKWebViewConfigurationExtensions` → `attachWebExtensions`), and the manager is created once at launch and replaced only by the flag handler. **Trigger unknown.** Candidates: web views created before the launch-time manager; the flag evaluating off at launch for some installs (missing or stale cached config); a web view built outside the standard configuration path. Macos 1.213 on 26 Oct: 51 users with controller mismatch + no scripts, 19 permanent (22% of macOS permanent hangs). The fix depends on the trigger. +- **Error 6: the P2 retry is shipped and helped.** iOS error-6 users fell from 1.3% to 0.5% of DAU, and 455 iOS users/day had a successful `background_load_retry`. Error-6 episodes have outcomes: iOS 86% recovered later, 9% permanent. It is still 25% of iOS stuck because (a) the retry restores the background but not the page whose `init` was lost, which nothing re-sends (late reload off); (b) the retry is skipped while the app is in the background, within the 60 s cooldown, or during M4; (c) when the failed background view is kept (H3, reproduced), the retry cannot complete. Which dominates is unknown: no retry attempted/result field in the episode. +- **Extension updated: yes, the outdated version is loaded.** `WebExtensionLifecycleCoordinator.loadAndSync` runs `loadInstalledExtensions()` (the previous, now outdated version) before `syncEmbeddedExtensions`, which installs the bundled version under a new identifier, loads it alongside, and unloads the old one. Early pages after an app update run against the old version, then the context is swapped with a new origin and the migration blackout. + +### Next steps +1. **Ship what's understood:** + - P3 release. + - Extension updated: upgrade before load at launch; carry the origin across upgrades. + - Error 6: restart the stale background on error 6 when the failed view is still alive, and re-init the page that lost `init`. + - P6: find the trigger first (the three candidates above), then fix. +2. **Verify the macOS Network-recovery false-positive lead:** recovery applies on 7.5% of macOS DAU vs 0.9% on iOS, and `died_client` precedes 16% of macOS idle-wake failures. Review `CPMNetworkProcessRecovery` detection; count recovery pixels in the harness screens. +3. **Telemetry** (one privacy review): events after the first failure (two-phase `bg_events`); a healthy-navigation baseline (background state on successful measurements); retry attempted/result; recovery applied in this episode; time since app resume. +4. **Targeted harness work only:** Network-recovery restart racing a wake; iOS resume-time wake on the simulator (fix the `Bundle.module` skip); the app-hosted macOS harness in a VM if steps 2–3 leave the wake group unexplained. +5. **Mitigation experiment:** keep the background warm while browsing (periodic `loadBackgroundContent` < 30 s), behind a flag; it is also a causal test for the wake group. +6. Re-measure on full days of 7.243 / 1.213 and the first P3 builds.