Гейт #2710 отвечает «источник собирается?». Он не отвечает на второй вопрос
#2659 — «а достаточно ли ttl_days, чтобы молчание означало снятие?». Пока свип
возвращается к строке реже, чем раз в ttl_days, TTL меряет нашу выборку, а не
жизнь объявления, — и источник при этом полностью здоров, так что гейт молчит.
Замер на проде 2026-08-09 (read-only): с деплоя гейта 06.08 TTL снял 1 028 строк,
127 из них (12.4%) уже снова активны — свип нашёл их живыми через 1-3 суток и
вернул сам. В Екатеринбурге, единственном городе с настоящим покрытием, доля
ложных снятий 100% (cian 103/103, yandex 24/24); возраст на момент снятия у всех
127 — 29.9..30.3 суток при TTL=30, то есть срабатывание ровно на границе.
Корень не в конкретном числе, а в том, что число подобрано руками ниже хвоста
обхода. Разрывы переобхода против текущих TTL (listing_source_snapshots, 40 сут):
domklik 3.1 при TTL=14 (4.5x запас, сплошное суточное покрытие — контрольная
группа), cian 26.6 при 30, yandex 43.0 при 30, avito 42.1 при 10. Поэтому второе
подобранное руками число проблему не решает.
Вместо константы меряем факт: какой самый большой возраст, при котором свип за
последнее окно ДОКАЗАЛ строку живой. Эффективный TTL = max(ttl_days, этот пол),
по тому же срезу source+segments и по той же колонке свежести, что и UPDATE.
Пол только поднимает порог. Побочный эффект намеренный: после провала сбора хвост
разрывов распухает, пол растёт, деактивация замирает сама — то, чего issue просил
от «гейта по банам», но выраженное через результат, а не через причину.
Тот же запрос на проде даёт cian/vtorichka 34.0, yandex/vtorichka 74.3,
avito 69.7, domklik NULL (сбор стоит, гейт его и так пропускает) — 235 мс,
раз в сутки. Квантиль 0.99 — калибровочная ручка в default_params расписания,
подобран по требованию «пол обязан накрыть возраст 30.3 доказанно ложных снятий».
Видимое пользователю: ближайший прогон Яндекса перестаёт снимать 43 активные
строки vtorichka; на проде это единственные строки, которых TTL сейчас касается.
Refs #2659
