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

This commit is contained in:
Alexey Martemyanov committed 2026-10-28 22:00:49 +06:00
1 parent d8a006fdb3
commit df3f05e53d
1 file changed
+6
@@ -362,3 +362,9 @@ Re-cut of the post-release data (macOS 1.213.x, 26–27 Oct, matured since the s
### Notes
- The "P3" lines above disagree: priorities say the baseURL fix is released; "What shipped" says P3 (#7493) is on main only and not in 1.213. Re-check before relying on either.
- Scratch SQL runner and queries are in the session scratchpad; the harness test is not committed or pushed.
### Addendum 28 Oct — error-page pixel and the sleep hypothesis
- There is an error-page pixel: `m.mac.errorpageshown.other` (+ `.daily`, `pixel_id='m'`, params `d`/`e` = error domain/code, `pixelSource`), fired in `Tab.swift` when the error page is shown, plus `m.mac.errorpageshown.webkittermination`. macOS 1.213, 26–27 Oct: 7,511 shows (2,284 install-days; ≈0.4 per loaded install-day). Codes: DNS `-1003` 29%, TLS `-1200/-1202…` 26%, connection lost `-1005` 10%, `-1004` and `-1001` a few % each; **offline `-1009` only 1.6% (122)**. So error pages are mostly dead hosts and certificate problems, not "no network after wake".
- Correlation with the wake group does not show up. Hourly counts correlate 0.88 with wake episodes and 0.88 with non-wake ones (both follow the rollout, so it says nothing). Per OS version (9 points) error pages per loaded install vs wake episodes per loaded install: r = 0.02 (vs 0.32 with non-wake). The pixel has no install id, so no per-install join.
- Reasoning against the wake link: the error document never sends `init`, so it does not wake the background. A failure counted on an error page would carry the background state as it was (after >30 s idle: no view; otherwise an old view), not a view created in the last 30 s. If error pages matter, they would sit in the "no view" and "other" cohorts rather than in wake. Not tested.
- The sleep/network-drop hypothesis above is therefore weak. The harness result (error pages are measured and counted as failures) stands as a monitor false-positive source; its size is bounded by the error-page rate (≤0.4 per install-day, most of it unrelated to wake). Filtering `.alternateHtmlLoad` in the monitor would remove it.