From 9c3df3acc7b3c9b09b4a31f8caedeb90ff193224 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 19 Oct 2026 20:43:24 +0600 Subject: [PATCH] [2026-10-19] eagle: work/projects/cpm-status-2026-10-15.md --- work/projects/cpm-status-2026-10-15.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/work/projects/cpm-status-2026-10-15.md b/work/projects/cpm-status-2026-10-15.md index e5d20cee..86cc8e81 100755 --- a/work/projects/cpm-status-2026-10-15.md +++ b/work/projects/cpm-status-2026-10-15.md @@ -132,6 +132,28 @@ tags: ## 6. Телеметрия +### Диагностическое покрытие Others — проверка 19 октября 2026 + +**Текущих данных недостаточно для полного объяснения Others CPM failures.** Проверены #7376 `39fe56af4c` и дополнения #7379 `8275bcce36`. #7376 помогает отличать состояния загрузки background и связывает первый сбой с наблюдаемым исходом эпизода. #7379 отдельно измеряет выбранные случаи первой загрузки и срабатывания recovery. Причины оставшихся внешне здоровых сбоев эти данные однозначно не разделяют. + +`reason=other` означает обычную навигацию вне restoration/crash/reload. Это не историческая диагностическая группа Others из §3–5. + +**Три пробела и необходимые измерения — предложения, отсутствующие в проверенных ревизиях:** + +- **Последний подтверждённый этап обмена и доставка `initResp`.** При готовом background остаются возможными потеря init-запроса, задержка native settings, потеря ответа странице и потеря dashboard-подтверждения при уже полученном страницей ответе. Нужны ограниченный enum последнего подтверждённого этапа и свидетельство получения ответа страницей. В исследовательском harness эти случаи различались через `init_stage`; в текущих PR такого параметра и page ACK нет. Dashboard-ответ не доказывает получение `initResp`. + +- **Конечный результат первоначально pending-загрузки.** Снимок фиксируется при первом timeout: если тогда записано `pending`, а на 30-й секунде приходит error 6, итоговый отчёт сохраняет `pending` и не включает позднюю ошибку, в том числе в `bg_events`. Это закреплено штатным тестом `testWhenContextChangesAfterFailureThenPixelKeepsFailureTimeDiagnostics`. Нужен конечный исход той же попытки загрузки, условно для эпизодов с исходным `pending`, без второго полного снимка или новой цепочки событий. + +- **Замена Network process относительно текущего background view.** `network_restarted` больше не передаётся; `network_replaced_since_view` отсутствует. Поэтому этот механизм нельзя надёжно отделить от остальных внешне здоровых сбоев, а старую классификацию Others нельзя напрямую повторить по новому payload. Нужен локально вычисляемый boolean смены Network process с момента создания текущего view; сами PID отправлять не нужно. + +Дополнения следует собирать локально в рамках эпизода и передавать только для целевых сигнатур как ограниченные enum/boolean в одном terminal report, сохраняя daily+count. Не добавлять идентификаторы, URL, точное время или дополнительную последовательность событий. Различимость сочетаний с сохранённым `bg_events` требует отдельной проверки; отсутствие идентификаторов само по себе её не гарантирует. + +Текущий контракт: [[cpm-pr0-episode-telemetry-summary-2026-10-16]]. Подтверждение границ: [состав отправляемого payload](https://github.com/duckduckgo/apple-browsers/blob/39fe56af4c35bf034d570f04dd58f59bd41eb2b6/SharedPackages/WebExtensions/Sources/WebExtensions/Pixels/WebExtensionPixelFiring.swift#L115-L146), [тест сохранения первого снимка после поздней error 6](https://github.com/duckduckgo/apple-browsers/blob/39fe56af4c35bf034d570f04dd58f59bd41eb2b6/SharedPackages/WebExtensions/Tests/WebExtensionsTests/CPMMessagingHealthMonitorTests.swift#L1330-L1362). Исследовательские проверки этапов обмена описаны ниже в разделе «Core suite завершён: 10/10, signed, штатный Vault». + +### Историческая оценка до перехода на единый эпизод + +Следующее описание относится к прежнему дизайну PR0, до замены отдельных failure/recovery-пикселей единым эпизодом. + **Что делает PR0 (#7376):** на 8 failure-пикселей и 2 recovery-пикселя добавлены параметры `bg_ready_after`, `bg_view_age`, `bg_load_error_after`, `bg_load_error_app_state`, `cpm_app_state`, `cpm_open_tabs`, `cpm_loading_tabs` (failure) и `cpm_recovery_document`, `cpm_recovery_after` (recovery). Новых пикселей нет. Recovery-пиксели получают только свои два параметра, `extension_reload_failed` без параметров. **Замечания ревьюера (JA1–JA3):** корреляция между пикселями из-за множества перечислений; сколько пикселей на ошибку; константность `cpm_open_tabs`/`cpm_app_state`; что такое background view.