From 03c7308ab755f13746d65fc20440b577990c186d Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Tue, 6 Oct 2026 11:19:04 +0600 Subject: [PATCH] [2026-10-06] eagle: work/projects/cpm-web-extension-breakage-validation.md work/projects/cpm-web-extension-public-attribution-2026-10-05.md --- .../cpm-web-extension-breakage-validation.md | 2 +- ...b-extension-public-attribution-2026-10-05.md | 17 +++++++++++++---- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/work/projects/cpm-web-extension-breakage-validation.md b/work/projects/cpm-web-extension-breakage-validation.md index cbb7d68c..c1fc2800 100755 --- a/work/projects/cpm-web-extension-breakage-validation.md +++ b/work/projects/cpm-web-extension-breakage-validation.md @@ -7,7 +7,7 @@ - Основной сигнал: 6 624 iOS и 1 377 macOS `initialization.failed.after.*.daily`; группы и контрольные суммы — в [[cpm-web-extension-public-attribution-2026-10-05]]. - На macOS есть 77 `init failure.daily` и 35 `stuck.daily` с controller mismatch и отсутствующими scripts **после** публикации tag; **до** публикации таких строк нет. Пиксели не содержат channel, поэтому отдельное событие нельзя строго назвать public-user report. - Session restoration failure сохраняется: 952 iOS / 68 macOS после tag. Долю временно восстановившихся по этому reason без связывания событий посчитать нельзя. -- M4 reload после confirmed stuck дал 916 iOS / 354 macOS `recovered.after.extension.reload.daily` от `messaging_stuck`; это успешные ответы, но не success rate всех эпизодов. +- Крупнейшая группа (3 717 iOS / 911 macOS init) имеет исправный native-снимок, но monitor не получил вовремя `refreshCpmDashboardState`. Это не доказывает потерю `initResp`: фактическая доставка в content script не измеряется. M4 после stuck дал 916 iOS / 354 macOS `recovered.after.extension.reload.daily`, подтверждая возобновление измеряемого background → native пути, но не всей CPM-функции. - До публикации macOS tag 5 октября было 28 init и 2 stuck; они вынесены в отдельный раздел отчёта вместе со ссылкой на более ранний internal-testing архив. ## Исторические проверки и планы diff --git a/work/projects/cpm-web-extension-public-attribution-2026-10-05.md b/work/projects/cpm-web-extension-public-attribution-2026-10-05.md index 01e67c50..6435cf1a 100755 --- a/work/projects/cpm-web-extension-public-attribution-2026-10-05.md +++ b/work/projects/cpm-web-extension-public-attribution-2026-10-05.md @@ -2,7 +2,7 @@ **Статус:** первый завершённый UTC-день с данными версий iOS 7.240.0 и macOS 1.210.0. Главный сигнал — `initialization.failed.after.*.daily`; `messaging.stuck.*.daily` проверен отдельно как более поздний, менее точный сигнал. Выгрузка сделана 6 октября из Grafana ClickHouse `metrics.pixels`, интервал `[2026-10-05 00:00, 2026-10-06 00:00) UTC`, `agent` и `appVersion` зафиксированы. **Основные таблицы ниже включают только события после публикации release tag каждой платформы**; отдельный раздел сохраняет всё попавшее в выгрузку до публикации. [Dashboard](https://grafana.duckduckgo.com/d/dfon7whlilnggb/cpm-weird-error-investigation?orgId=1). -**Вывод:** после публикации macOS tag есть **77** первых init failures и **35** stuck с несовпадающим controller вкладки и отсутствующими extension scripts; **до публикации таких строк нет**. iOS session restoration по-прежнему даёт 952 первых сбоя, из них 604 со совпадающим controller, но без scripts и background view; у macOS после публикации таких session-restoration сбоев 68, из них 12 с той же сигнатурой. Восстановление после reload наблюдается гораздо чаще, чем в предыдущих релизах; оно реально достигает успешного CPM-ответа, но долю успешных попыток эти пиксели не измеряют. Эффект исправлений tab lifecycle в совокупном тренде не выделяется. +**Вывод:** после публикации macOS tag есть **77** первых init failures и **35** stuck с несовпадающим controller вкладки и отсутствующими extension scripts; **до публикации таких строк нет**. iOS session restoration по-прежнему даёт 952 первых сбоя, из них 604 со совпадающим controller, но без scripts и background view; у macOS после публикации таких session-restoration сбоев 68, из них 12 с той же сигнатурой. **Крупнейшая группа с «исправным native-снимком» не доказывает нормальную загрузку или потерю `initResp`: health monitor измеряет отдельный вызов background → native `refreshCpmDashboardState`.** После reload этот вызов вновь наблюдается гораздо чаще, но восстановление фактического `initResp` из пикселей не следует. Эффект исправлений tab lifecycle в совокупном тренде не выделяется. ## 1. Охват и контрольные суммы @@ -45,7 +45,16 @@ 4. **macOS `other`, 1 050.** 713 выглядят исправно, 132 не имеют живого background view, 110 имеют только историческую context error, 47 — неверный controller без scripts. За все причины init неверный controller без scripts есть у **77/1 377 после tag и 0/28 до tag**; в stuck — **35/487 после tag и 0/2 до tag**. Init-сигнатура встречается с 10:34 до 23:21 UTC, а не только сразу после публикации в 09:46. Из 77 после tag 45 имеют `app_version_change=updated`. App update сам по себе не сохраняет старый `WKWebView`; эти строки не доказывают сценарий «вкладка осталась у старого контроллера после обновления». Требуется событие смены manager/controller при живой вкладке. 5. **iOS `tab.crash`, 199.** 47 имеют code 6, 37 — явную смерть background процесса, 35 — scripts отсутствуют и background view не создан. Название reason означает навигацию после crash вкладки, а не установленную смерть CPM worker. -Вторичный stuck сдвигает iOS-картину: background state 768/6 624 (11,6%) на первом сбое против 457/1 440 (31,7%) на stuck; no-scripts/zero-view 917/6 624 против 52/1 440. Это согласуется с временными startup misses и более устойчивой background-проблемой, **но это не переходная вероятность**: имена `.daily` считаются независимо. У iOS code 6 находится в 364 stuck снимках (в 363 `dealloc` раньше первой ошибки); WebKit регистрирует code 6 как `BackgroundContentFailedToLoad` после неудачной загрузки service worker. Причина отказа регистрации из пикселя неизвестна. Хвост `bg_events` ограничен 12 событиями и может обрезать старые события. «Native snapshot без видимой ошибки» означает, что текущих полей недостаточно для локализации content script → worker → native → page ответа, а не что пользовательского сбоя не было. +Вторичный stuck сдвигает iOS-картину: background state 768/6 624 (11,6%) на первом сбое против 457/1 440 (31,7%) на stuck; no-scripts/zero-view 917/6 624 против 52/1 440. Это согласуется с временными startup misses и более устойчивой background-проблемой, **но это не переходная вероятность**: имена `.daily` считаются независимо. У iOS code 6 находится в 364 stuck снимках (в 363 `dealloc` раньше первой ошибки); WebKit регистрирует code 6 как `BackgroundContentFailedToLoad` после неудачной загрузки service worker. Причина отказа регистрации из пикселя неизвестна. Хвост `bg_events` ограничен 12 событиями и может обрезать старые события. + +### Проверка по коду: что означает «исправный native-снимок» + +1. **Пиксель измеряет отсутствие отдельного native-вызова.** После `navigationDidFinish` при наличии context (или после lifecycle `loaded`) monitor ждёт до 4 секунд `dashboardResponse`, который поступает только из `AutoconsentWebExtensionMessageHandler.handleRefreshCpmDashboardState` при вызове `refreshCpmDashboardState`. Если на `navigationDidFinish` extension отсутствует, действует отдельное 30-секундное ожидание с отменой измерения. По истечении 4-секундного таймера `reportFailure` собирает снимок **на тот момент**. `isAutoconsentExtensionLoaded` проверяет наличие embedded context в controller, не готовность CPM JS. +2. **`context_loaded=true` не означает завершённый startup.** В просмотренном `WebKit_sparse` `isLoaded()` означает наличие `m_extensionController`; он назначается до асинхронного `moveLocalStorageIfNeeded`, создания background view, регистрации scripts и `addInjectedContent()`. `bg_view_alive=true` означает живой `WKWebView`, а `bg_process_responsive=true` — что WebKit не признал его зависшим; это не проверка выполненного service worker listener. `tab_has_ext_scripts=true` проверяет список зарегистрированных `WKUserScript`, но не их выполнение в текущем документе. `handler_registered=true` проверяет запись в native router, но не факт обработки сообщения. +3. **`initResp` и наблюдаемый monitor сигнал расходятся в release bundle.** Content script отправляет `init` в background. В успешной ветке background делает `updateCpmDashboardState(...).then(refreshDashboardState(...))` **без await**, затем отдельно вызывает `chrome.tabs.sendMessage(..., {type: "initResp"})`. В ветках `config_unavailable`, `settings_missing`, `setting_disabled`, `site_disabled` он отправляет dashboard refresh и возвращается **без `initResp`**. Значит, `init failure.daily` возможен даже после отправки `initResp`, если dashboard refresh задержался или не сопоставился с документом; обратное тоже возможно: успешный health-сигнал без `initResp`. +4. **Есть конкретные места задержки и ложной атрибуции.** Background перед успешной веткой ждёт remote config и native setting/site checks; native request timeout в bundled JS — 20 секунд против 4-секундного окна monitor. Обновление dashboard state проходит через последовательную async-очередь и session storage. Monitor сопоставляет URL refresh с текущим документом по scheme/host/port/path/**query**; несоответствие или опоздание оставит timeout даже при работающем JS. Сколько случаев пришло из каждого участка, текущие пиксели не показывают. + +Эта проверка проведена именно на bundle из release tags `1.210.0+macos` и `7.240.0+ios` (zip-файлы совпадают); текущий `main` уже содержит другой bundle. Приоритет следующей telemetry — отдельные времена `content init sent`, `background init received`, `initResp sent/received`, `dashboard refresh sent/received` и результат сопоставления URL. ## 3. Session restoration: ушли ли временные сбои? @@ -59,9 +68,9 @@ ## 5. After-stuck recovery mitigation: работает ли? -**Функциональный сигнал есть.** [M4](https://github.com/duckduckgo/apple-browsers/commit/41656f8d17) входит в macOS 1.210 / iOS 7.240 и при подтверждённом hang пытается reload embedded extension (remote flag по умолчанию enabled). `recovered.after.extension.reload.daily` отправляется только после реального успешного CPM-ответа текущего поколения extension. После публикации таких событий от `messaging_stuck` — **916 iOS / 354 macOS**. Все `recovered.after` вместе дают 963/1 440 = **66,9%** от числа stuck daily на iOS и 362/487 = **74,3%** на macOS, тогда как в предшествующих пятидневных окнах число пикселей этого имени относительно stuck daily составляло **3,23%** (iOS 7.239) и **2,70%** (macOS 1.209). Это большой скачок, согласующийся с автоматическим reload. Эти отношения **не success rate**: имена пикселей независимо throttled, эпизоды не соединены, одни установки могли дать несколько разных сигналов. +**Узкий функциональный сигнал есть.** [M4](https://github.com/duckduckgo/apple-browsers/commit/41656f8d17) входит в macOS 1.210 / iOS 7.240 и при подтверждённом hang пытается reload embedded extension (remote flag по умолчанию enabled). `recovered.after.extension.reload.daily` означает, что после reload текущего поколения снова поступил и был сопоставлен **native dashboard refresh**; получение `initResp` content script этот пиксель не проверяет. После публикации таких событий от `messaging_stuck` — **916 iOS / 354 macOS**. Все `recovered.after` вместе дают 963/1 440 = **66,9%** от числа stuck daily на iOS и 362/487 = **74,3%** на macOS, тогда как в предшествующих пятидневных окнах число пикселей этого имени относительно stuck daily составляло **3,23%** (iOS 7.239) и **2,70%** (macOS 1.209). Это большой скачок, согласующийся с автоматическим reload. Эти отношения **не success rate**: имена пикселей независимо throttled, эпизоды не соединены, одни установки могли дать несколько разных сигналов. -**Ограничение эффекта:** после публикации первый post-reload CPM probe всё ещё завершился timeout 670 раз на iOS и 232 на macOS, поэтому reload не гарантирует немедленного восстановления. Это не сбой самого API reload. Отдельный `debug.web.extension.reload.failed.daily` после публикации содержит один macOS error для `embedded / cpm_messaging_hung / load` и 223 iOS errors для **другого** `adBlocking / scriptlet_update / unload` extension; до публикации этих operation errors нет. На текущих данных M4 действительно возвращает ответы после stuck у части установок; нельзя вычислить долю всех stuck-эпизодов, которые остались невосстановленными, или изменение общей частоты init failures. +**Ограничение эффекта:** после публикации первый post-reload CPM probe всё ещё завершился timeout 670 раз на iOS и 232 на macOS, поэтому reload не гарантирует немедленного восстановления даже измеряемого native-вызова. Это не сбой самого API reload. Отдельный `debug.web.extension.reload.failed.daily` после публикации содержит один macOS error для `embedded / cpm_messaging_hung / load` и 223 iOS errors для **другого** `adBlocking / scriptlet_update / unload` extension; до публикации этих operation errors нет. На текущих данных M4 восстанавливает измеряемый background → native путь у части установок; нельзя вычислить долю stuck-эпизодов с полноценным `initResp` и CPM-функцией, которые остались невосстановленными, или изменение общей частоты init failures. ## Источники и воспроизведение сверки