tradein: сторож «ноль результатов» структурно слеп к backfill-задачам — читает поле, которого в их счётчиках нет, поэтому 78 пустых прогонов из 158 … #2703

New issue

Closed

opened 2026-08-06 06:22:23 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-08-06 06:22:23 +00:00

Collaborator

Найдено при разборе domclick_detail_backfill (эпик #2674, PR #2695). Объясняет, почему 30 подряд пустых прогонов никто не заметил — и почему это повторится на других задачах.

Два сторожа, и оба слепы именно к backfill'ам

_alert_if_consecutive_failures считает подряд идущие failed/banned. До PR #2695 пустые backfill-прогоны назывались done, поэтому стрик не набирался никогда. Это половина починена.

_alert_if_consecutive_zero_results (#2625) смотрит total_seen. У backfill'ов в счётчиках такого поля нет вообще — они пишут attempted/enriched/blocked/failed. Колонка читается как 0 всегда, в том числе у полностью успешного прогона. Стрик «нулевых результатов» поэтому не прерывается никогда, а анти-спам, срабатывающий один раз на стрик, замолкает после первого события — навсегда.

То есть второй сторож не просто не сработал: он структурно не может сработать по этим задачам, и при этом выглядит настроенным.

Масштаб

Прогонов вида «попытки были, результата ноль» — 78 из 158 по трём backfill-задачам:

source	таких	самое заметное
`domclick_detail_backfill`	24/30	494 попытки → 0
`avito_detail_backfill`	23/76	5 прогонов по 1500–1600 попыток с нулём обогащений
`yandex_detail_backfill`	31/52	все ровно `attempted=5 failed=5`

Полторы тысячи попыток и ноль результата — это уже не «тихий сбой», это заметная работа, потраченная впустую и не отражённая нигде.

Что нужно

Свести счётчики backfill'ов к тому, что читает сторож (total_seen ↔ attempted), либо научить сторож их словарю. Первое проще, второе честнее — решать по тому, сколько ещё задач имеют собственный словарь счётчиков.
Проверить остальные задачи на тот же разрыв: сторож молча читает 0 у любой задачи, чьи счётчики он не знает. Сейчас неизвестно, сколько их.
Анти-спам «один раз на стрик» безопасен только если стрик может прерваться. Там, где условие прерывания недостижимо, он превращается в «один раз навсегда» — это стоит сделать невозможным по построению, а не полагаться на корректность счётчиков.

Отдельно: сама доставка уведомлений не настроена (#2673) — за всю историю продукта наружу не ушло ни одного. Даже починенный сторож будет срабатывать в пустоту, пока это так.

Связано: #2674, #2673, #2625, #2695, #2670.

Найдено при разборе `domclick_detail_backfill` (эпик #2674, PR #2695). Объясняет, **почему** 30 подряд пустых прогонов никто не заметил — и почему это повторится на других задачах. ## Два сторожа, и оба слепы именно к backfill'ам **`_alert_if_consecutive_failures`** считает подряд идущие `failed`/`banned`. До PR #2695 пустые backfill-прогоны назывались `done`, поэтому стрик не набирался никогда. Это половина починена. **`_alert_if_consecutive_zero_results`** (#2625) смотрит `total_seen`. У backfill'ов в счётчиках такого поля **нет вообще** — они пишут `attempted`/`enriched`/`blocked`/`failed`. Колонка читается как 0 **всегда**, в том числе у полностью успешного прогона. Стрик «нулевых результатов» поэтому не прерывается никогда, а анти-спам, срабатывающий один раз на стрик, замолкает после первого события — навсегда. То есть второй сторож не просто не сработал: он структурно не может сработать по этим задачам, и при этом выглядит настроенным. ## Масштаб Прогонов вида «попытки были, результата ноль» — **78 из 158** по трём backfill-задачам: | source | таких | самое заметное | |---|---:|---| | `domclick_detail_backfill` | 24/30 | 494 попытки → 0 | | `avito_detail_backfill` | 23/76 | **5 прогонов по 1500–1600 попыток** с нулём обогащений | | `yandex_detail_backfill` | 31/52 | все ровно `attempted=5 failed=5` | Полторы тысячи попыток и ноль результата — это уже не «тихий сбой», это заметная работа, потраченная впустую и не отражённая нигде. ## Что нужно 1. Свести счётчики backfill'ов к тому, что читает сторож (`total_seen` ↔ `attempted`), **либо** научить сторож их словарю. Первое проще, второе честнее — решать по тому, сколько ещё задач имеют собственный словарь счётчиков. 2. Проверить остальные задачи на тот же разрыв: сторож молча читает 0 у любой задачи, чьи счётчики он не знает. Сейчас неизвестно, сколько их. 3. Анти-спам «один раз на стрик» безопасен только если стрик может прерваться. Там, где условие прерывания недостижимо, он превращается в «один раз навсегда» — это стоит сделать невозможным по построению, а не полагаться на корректность счётчиков. Отдельно: **сама доставка уведомлений не настроена** (#2673) — за всю историю продукта наружу не ушло ни одного. Даже починенный сторож будет срабатывать в пустоту, пока это так. Связано: #2674, #2673, #2625, #2695, #2670.

~~bot-backend referenced this issue 2026-08-06 06:23:36 +00:00~~

[ВЛАДЕЛЬЦУ] Сводка: 8 пунктов, которые не чинятся кодом — учётки, ключи, получатель уведомлений, два решения #2704

Rows
Columns

tradein: сторож «ноль результатов» структурно слеп к backfill-задачам — читает поле, которого в их счётчиках нет, поэтому 78 пустых прогонов из 158 … #2703

Два сторожа, и оба слепы именно к backfill'ам

Масштаб

Что нужно

ЗАКРЫВАЮ: слепая зона стала выразимой, пустые backfill'ы ловятся — 4 из 4 против 0 из 78