[2026-10-27] eagle: work/projects/cpm-post-release-analysis-2026-10-27.md

work/projects/cpm-post-release-analysis-2026-10-27.md

@@ -197,3 +197,18 @@ The harness differs from macOS production in four ways:
 
 `reloadExtension` itself returns in ~20 ms; the delay is WebKit migrating extension data to the new origin before content scripts run. Roughly linear, ~50 µs per cache entry. Cookie seeding on 5,000 `.test` domains did not create website data records (still 2), so per-site record cost is untested. The same migration runs on every **app launch** in released builds, which links this to the P3 startup cohort. **P3 (#7493) removes it in both cases.** It explains `reload_state=response_timed_out` and extended post-reload silence; whether real caches are large enough for a full 5-minute silence is being checked at 600,000 entries.
 - **600,000 entries, released origin:** first `initResp` **32.2 s** after the reload, **5 navigations lost**; still linear (~53 µs/entry). Page loads during the migration were also slower (one took 9 s), so the migration may delay browsing generally, not only CPM. A full 5-minute silence would need ~5–6M entries by extrapolation, so this explains post-reload silences of seconds to about a minute, not the whole deadline. The same blackout hits **every app launch** on released builds. With P3, 0.1 s at every size.
+
+### What survives the hang reload — code search and tests (27 Oct)
+
+Telemetry: every confirmed permanent hang (iOS 0.30%, macOS 2.07% of DAU) had the M4 reload run and stay silent, so the broken state survives a full context replacement or the trigger repeats. Checked:
+- **Native messaging** (`WebExtensionMessageRouter`, `AutoconsentWebExtensionMessageHandler`): handlers keyed by extension identifier and re-registered on reload; each request is stateless. Not persistent.
+- **Monitor reload bookkeeping:** responses from measurements begun on the new generation count; harness reload scenarios closed their episodes. No bug found.
+- **WebKit process reuse:** `WebProcessCache` requires `usesWebProcessCache`, default false, and the app sets no process-pool options. Ruled out.
+- **`storage.session` stall:** CPM's `refreshRemoteConfig` awaits `getFromSessionStorage("config")` with no timeout, so a stall would hang every `init`. No stall in any screen log; only `tabs.sendMessage` on the busy-page profile. Not reproduced.
+- **Network replaced while the background is unloaded** (`testNetworkProcessReplacedWhileBackgroundIsUnloadedKeepsWakesWorking`, 30 s timing): 0 lost in 6 busy navigations and 4 idle wakes.
+- **macOS tab URL:** `Tab.url(for:)` returns `content.urlForWebView`, which follows `webView.url` one main-queue hop later; WebKit reads it live for `sender.tab.url`. Harness mode `CPM_REPRO_MACOS_TAB_URL=1` reproduces the lag: 133 real-page visits, 0 lost, **0 monitor episodes**. `init` arrives after the hop.
+- **`webExtensionPageWebView`:** only set for `webkit-extension:` pages and cleared on content change. Not relevant.
+
+**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.