git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Alexey Martemyanov committed 2026-10-27 18:26:00 +06:00
1 parent ac34e6b73b
commit ba3a6e7a19
1 file changed
+8
Download Patch File Download Diff File Expand all files Collapse all files
work/projects/cpm-post-release-analysis-2026-10-27.md
+8
View File
@@ -188,3 +188,11 @@ The harness differs from macOS production in four ways:
- **App Store vs DMG** (macOS 1.213, 26–27 Oct, per loaded install): episodes 20.8% vs 29.7%, wake cohort 9.8% vs 10.6%, cross-tab no-response 1.2% vs 2.4%. Sandboxing does not drive the wake cohort; the DMG excess is likely early-updater bias.
- **Real-page screen** (`CPMReproRealPageTests`): earlier repro tests used `loadSimulatedRequest`, so loads never reached WebKit's Network process. `CPMReproFixtureServer` serves loopback pages through it: cross-origin iframes (`localhost` vs `127.0.0.1`), 302 redirects, `replaceState`, slow images, main-thread blocks. CPM + ad-blocking, fast unload, 1,000 cycles: **0 lost of 1,333 visits** across 7 profiles (~190 each), and no monitor episodes. Real loads, frames, redirects and URL rewrites do not trigger the wake hang.
- **Next hypothesis — origin-changing M4 reload stalls on large data:** most confirmed macOS cross-tab hangs (1.213, 26–27 Oct, `tabs_affected≠1` and no response) have tail `proxy_on>dealloc>view>proxy_on`, view 4–8 s, ready <1 s, scripts present, **`reload_state=loaded` (97+22+22) or `response_timed_out` (34+17+13)**. The reload loaded, yet nothing answered for the rest of the episode. Released builds load the reloaded context under a new random origin, and P3 saw WebKit's origin migration slow with a large cache. Test: `CPMReproReloadOriginTests` fills the persistent HTTP cache (`/fill`, default 20,000 × 2 KB) and runs the M4 reload with released vs stable origin, timing post-reload silence. If confirmed, P3 also fixes hang persistence.
- **Reproduced: origin-changing M4 reload blacks out CPM proportionally to the HTTP cache** (`CPMReproReloadOriginTests`, production timing, CPM only). Fill the persistent cache through real fetches, run the hang reload (`reloadExtension(…, trigger: .cpmMessagingHang)`), navigate every 2 s:
| Cache entries (2 KB) | Released origin (new random origin per load) | P3 stable origin |
|---|---|---|
| 20,000 | first `initResp` 1.5 s after reload, 0 lost | 0.1 s |
| 200,000 | **10.9 s, 1 lost** | 0.1 s |
`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.