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

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

@@ -98,3 +98,5 @@ Worktree `apple-browsers.git/cpm-remaining-failures-repro`, branch `alex/cpm-rem
 
 - **R1 idle wake — not reproduced organically.** `CPMReproIdleWakeTests.testRepeatedIdleWakeCyclesDeliverInit`: 3 tabs, 8 idle-unload cycles (WebKit unloads 32.0 s after the last answered navigation), single and double-tab wakes, 0 of 11 lost. Every wake answered in 2–5 ms after didFinish. `testNavigationAtIdleUnloadBoundaryDeliversInit`: offsets −0.6…+0.2 s around the calibrated unload, 0 of 7 lost. A plain idle wake on an in-memory fixture page is not the production mechanism. The missing ingredient is still unknown: real page loads, a long-lived data store with abandoned registrations, Network replacement, or listener-set loss.
 - **P3 (#7493) only in internal builds** (macOS 1.214.0-860, iOS 7.244.0-x). On 26 Oct: macOS 1.214 had 20 episodes / 9 daily of ~36 loaded installs, with 0 no-view and 0 error 6; iOS 7.244 had none. That is too small to evaluate. Relevance: released builds get a new random extension origin on every context load (launch and M4 reload), and WebKit migrates data before injecting. This may explain the iOS no-view cohort and the macOS "reload loaded → still no response" share (46%). Re-check when 7.244 reaches users.
+- **R2 suspended wake — macOS analogue does not stay broken.** `CPMReproSuspendedWakeTests`: idle unload, then a navigation wakes the background, and the new background process is SIGSTOPped for 45 s while another tab navigates every 10 s. Two navigations timed out (+9 s, +14 s). Then the background was replaced by a new process (same view slot, new PID) and every later navigation answered in 1–14 ms, including 10 after thaw. No error 6 was recorded on the live context. On macOS the shipped recovery restores messaging within ~14 s of the fault. The harness cannot reproduce iOS suspension, which pauses the UI process's own timers. Likely production sequence: the overdue 30 s unload timer fires at resume, closes the loading view, and records error 6 "under 5 s" (pattern A). Pattern B (new view pending 8–30 s) needs a device or simulator test.
+- WebKit hypothesis not hit yet: an SW load failure that **keeps** the background view (`loadBackgroundWebView` completion `!success` without unload). Later wakes would only queue, and every dispatch restarts the 30 s unload timer, so the public `loadBackgroundContent`/P2 retry cannot escape. A candidate mitigation is to restart the background web content process when error 6 is recorded while a background view still exists. Not implemented, because the state has not been reproduced.