lekss361/gendesign

Fork 0

tradein/avito: решить по данным 9–10.08 — нужны ли два недельных полных обхода, и как делать пробный прогон с узким окном #2687

New issue

Open

opened 2026-08-05 23:14:09 +00:00 by bot-backend · 9 comments

bot-backend commented

2026-08-05 23:14:09 +00:00

Collaborator

Два вопроса, всплывших при починке окна ретроспективы (#2685). Оба намеренно не решены в коде — для решения нужны данные, которых пока нет.

1. Полный обход и исчерпывающий почти дублируют друг друга

После приведения окна к такту avito_full_load (окно 7 суток) и avito_full_load_exhaustive (без отсечки по дате) — это один и тот же обход с разной глубиной. Оба недельные, ближайшие запуски 9 и 10 августа, то есть два тяжёлых обхода Авито подряд.

Разница только в хвосте: исчерпывающий добирает лоты старше 13 суток по нашей квантованной шкале — то есть те, что не двигались две недели. А цена по ним в оценщике всё равно берётся из четырнадцатидневного окна свежести.

Предварительный вывод: исчерпывающий нужен не еженедельно, а раз в месяц-полтора, как сверка инвентаря. Он же — единственный источник честного знаменателя для замеров вроде того, которым обосновывали окно.

Но менять такт сейчас нельзя: оба прогона в текущем виде ни разу не дошли до конца (см. #2686 — их убивал наш собственный сайдкар). Решать надо по первому успешному прогону обоих на исправленном коде, а не по рассуждению.

Что смотреть 9–10 августа: сколько лотов добирает исчерпывающий сверх полного, и сколько из них реально влияют на оценки (то есть попадают в окно свежести). Если добавка мала — переводить на месячный такт.

2. Пробный прогон с узким окном стал невозможен

Планировщик поднимает окно до такта и никогда не сужает. Комментарий миграции обещает уважение к осознанному выбору оператора, но обещание одностороннее: дешёвый пробный прогон с окном в сутки при недельном такте теперь требует правки кода.

Правильное решение — различать плановый запуск и ручной: плановому окно поднимать, ручному с явно заданным параметром доверять. Но такого различения у нас нет вовсе, оба идут одним путём с параметрами из строки расписания, и заводить новое поле ради пробного прогона несоразмерно.

Обходной путь есть и он в одну строку: временно поставить такт в сутки вместе с окном — что как раз и есть правило «менять такт и окно одной правкой».

Решать надо, если пробные прогоны с узким окном понадобятся регулярно. Тогда это отдельный флаг в параметрах расписания или одноразовые параметры следующего запуска, а не догадка планировщика.

Связано: #2685, #2686, #2674.

Два вопроса, всплывших при починке окна ретроспективы (#2685). Оба намеренно **не решены в коде** — для решения нужны данные, которых пока нет. ## 1. Полный обход и исчерпывающий почти дублируют друг друга После приведения окна к такту `avito_full_load` (окно 7 суток) и `avito_full_load_exhaustive` (без отсечки по дате) — это один и тот же обход с разной глубиной. Оба недельные, ближайшие запуски 9 и 10 августа, то есть два тяжёлых обхода Авито подряд. Разница только в хвосте: исчерпывающий добирает лоты старше 13 суток **по нашей квантованной шкале** — то есть те, что не двигались две недели. А цена по ним в оценщике всё равно берётся из четырнадцатидневного окна свежести. Предварительный вывод: исчерпывающий нужен **не еженедельно, а раз в месяц-полтора**, как сверка инвентаря. Он же — единственный источник честного знаменателя для замеров вроде того, которым обосновывали окно. **Но менять такт сейчас нельзя**: оба прогона в текущем виде **ни разу не дошли до конца** (см. #2686 — их убивал наш собственный сайдкар). Решать надо по первому успешному прогону обоих на исправленном коде, а не по рассуждению. Что смотреть 9–10 августа: сколько лотов добирает исчерпывающий сверх полного, и сколько из них реально влияют на оценки (то есть попадают в окно свежести). Если добавка мала — переводить на месячный такт. ## 2. Пробный прогон с узким окном стал невозможен Планировщик поднимает окно до такта и **никогда не сужает**. Комментарий миграции обещает уважение к осознанному выбору оператора, но обещание одностороннее: дешёвый пробный прогон с окном в сутки при недельном такте теперь требует правки кода. Правильное решение — различать плановый запуск и ручной: плановому окно поднимать, ручному с явно заданным параметром доверять. Но такого различения у нас нет вовсе, оба идут одним путём с параметрами из строки расписания, и заводить новое поле ради пробного прогона несоразмерно. Обходной путь есть и он в одну строку: временно поставить такт в сутки **вместе** с окном — что как раз и есть правило «менять такт и окно одной правкой». **Решать надо, если пробные прогоны с узким окном понадобятся регулярно.** Тогда это отдельный флаг в параметрах расписания или одноразовые параметры следующего запуска, а не догадка планировщика. Связано: #2685, #2686, #2674.

bot-backend referenced this issue

2026-08-06 00:48:30 +00:00

[HIGH] tradein: статус «забанен» на инфраошибке — из-за него сбор Авито замедлили вдвое по ложному основанию #2686

bot-backend referenced this issue

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

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

Light1YT referenced this issue from a commit

2026-08-06 08:14:07 +00:00

fix(tradein/scraper): статус «забанен» перестаёт выдавать наш сбой за чужой (#2686)

bot-backend referenced this issue

2026-08-06 08:14:34 +00:00

fix(tradein/scraper): статус «забанен» перестаёт выдавать наш сбой за чужой (#2686) #2711

bot-backend referenced this issue

2026-08-06 08:49:09 +00:00

[HIGH] tradein: статус «забанен» на инфраошибке — из-за него сбор Авито замедлили вдвое по ложному основанию #2686

bot-backend commented

2026-08-06 10:16:37 +00:00

Author

Collaborator

Вход в это решение надо пересобрать: оба полных обхода не отрабатывали больше месяца

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

источник                     последний успешный прогон
avito_full_load              2026-07-03 14:06     ← 34 дня назад
avito_full_load_exhaustive   2026-06-21 13:00     ← 46 дней назад
cian_full_load               2026-08-02 21:25     ← в порядке

Расклад по avito_full_load за всю историю: banned 28, failed 20, cancelled 11, done 9 (последний 03.07), zombie 5.

Почему это не было заметно

Найдено при разборе #2670: за 31 подряд неудачный прогон avito_full_load наружу ушло ровно одно напоминание — на третьей неудаче. Сторож устроен так, что после первого срабатывания на стрике замолкает до его прерывания, а стрик не прерывался 34 дня. Починено в PR #2720 (лестница напоминаний N, 2N, 4N… и не реже одной на 16×N прогонов).

Второй слой: значительная часть тех неудач носила метку «нас забанила площадка», а на деле была отказом нашего собственного браузерного сайдкара — 92 прогона из 115 (#2686, разведено в PR #2711).

Что это значит для решения

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

Предлагаю переформулировать: сначала добиться, чтобы avito_full_load завершался, и только потом решать, нужен ли второй. Проверяемое условие для 9–10.08 — есть ли хотя бы один done после 06.08; если нет, решение о такте принимать не на чем, и надо разбирать, почему обход не доходит до конца.

Отдельно напомню, что деградация такта из миграции 206 была принята на ложном основании (#2686) и продолжает действовать. Снимать её вслепую я не предлагаю — но и держать как «осознанное решение по данным» больше нельзя: данных под ним не было.

## Вход в это решение надо пересобрать: оба полных обхода не отрабатывали больше месяца Задача сформулирована как «нужны ли **два** недельных полных обхода Авито». Проверка на проде показывает, что вопрос сейчас стоит иначе — сравнивать нечего. ``` источник последний успешный прогон avito_full_load 2026-07-03 14:06 ← 34 дня назад avito_full_load_exhaustive 2026-06-21 13:00 ← 46 дней назад cian_full_load 2026-08-02 21:25 ← в порядке ``` Расклад по `avito_full_load` за всю историю: `banned` 28, `failed` 20, `cancelled` 11, `done` **9** (последний 03.07), `zombie` 5. ## Почему это не было заметно Найдено при разборе #2670: за 31 подряд неудачный прогон `avito_full_load` наружу ушло **ровно одно** напоминание — на третьей неудаче. Сторож устроен так, что после первого срабатывания на стрике замолкает до его прерывания, а стрик не прерывался 34 дня. Починено в PR #2720 (лестница напоминаний `N, 2N, 4N…` и не реже одной на `16×N` прогонов). Второй слой: значительная часть тех неудач носила метку «нас забанила площадка», а на деле была отказом нашего собственного браузерного сайдкара — 92 прогона из 115 (#2686, разведено в PR #2711). ## Что это значит для решения Вопрос «нужны ли два обхода» предполагает, что оба работают и надо выбрать. Фактически **ни один не отработал за последний месяц**, поэтому по данным 9–10.08 сравнивать будет нечего — если только к этому моменту хотя бы один не начнёт завершаться успешно. Предлагаю переформулировать: сначала добиться, чтобы `avito_full_load` завершался, и только потом решать, нужен ли второй. Проверяемое условие для 9–10.08 — **есть ли хотя бы один `done` после 06.08**; если нет, решение о такте принимать не на чем, и надо разбирать, почему обход не доходит до конца. Отдельно напомню, что деградация такта из миграции 206 была принята на ложном основании (#2686) и продолжает действовать. Снимать её вслепую я не предлагаю — но и держать как «осознанное решение по данным» больше нельзя: данных под ним не было.

bot-backend commented

2026-08-06 10:58:44 +00:00

Author

Collaborator

Уточнение к предыдущему комментарию: прогресс есть, но проверить его будет нечем до 10.08

Я написал «ни один полный обход не отработал за последний месяц». По успешному завершению это верно (последний done — 03.07), но картина по бакетам мягче:

прогон  дата         бакетов пройдено   собрано
3074    2026-08-03            7           362
2986    2026-08-02            0             0
2889    2026-08-01            0             0
2809    2026-07-31            0             0
...     до 27.07              0             0

Последний прогон впервые за месяц сдвинулся с нуля — взял 7 бакетов и 362 объявления, прежде чем получил инфраструктурный бан. Чекпоинт при этом сохранился, что теперь видно явно после разведения статусов (#2711): все эти отказы помечены ban_kind='infra', ни одного platform.

Причина отказов у всех одна и та же — browser unavailable (proxy may be down) на первой же странице.

Что это значит для даты решения

avito_full_load идёт недельным тактом, следующий запуск — 2026-08-10 14:16 UTC. Последний состоялся 03.08.

Значит все починки прокси-тракта, приземлившиеся после 03.08 — #2634/#2640 (04.08) и #2708 (06.08, домовая оценка ходила мимо пула) — этим обходом ни разу не проверялись. К 9–10.08 будет ровно одна наблюдаемая точка, и она же будет первым прогоном на исправленном тракте.

Отсюда практическое предложение по срокам: решение о том, нужны ли два обхода, имеет смысл принимать не раньше чем через два-три прогона после 10.08. Одна точка ничего не различит: если она удачна — неизвестно, устойчиво ли это; если неудачна — неизвестно, дело в такте или в тракте.

Состояние пула на сейчас

id  метка                  affinity   включён
1   asocks-residential-1   domclick   да
9   asocks-mobile-1        any        да   ← забанен для avito до 11:52 сегодня
10  asocks-mobile-2        any        да
11  asocks-mobile-3        any        да

Три узла общего назначения на все источники, один из них сейчас под баном по паре (источник × прокси). Это ровно та теснота, о которой #2638: ротация написана и не может включиться без токена. Пока её нет, «browser unavailable» будет повторяться независимо от такта — и, значит, любое решение по такту будет приниматься на данных, испорченных нехваткой адресов.

## Уточнение к предыдущему комментарию: прогресс есть, но проверить его будет нечем до 10.08 Я написал «ни один полный обход не отработал за последний месяц». По успешному завершению это верно (последний `done` — 03.07), но картина по бакетам мягче: ``` прогон дата бакетов пройдено собрано 3074 2026-08-03 7 362 2986 2026-08-02 0 0 2889 2026-08-01 0 0 2809 2026-07-31 0 0 ... до 27.07 0 0 ``` **Последний прогон впервые за месяц сдвинулся с нуля** — взял 7 бакетов и 362 объявления, прежде чем получил инфраструктурный бан. Чекпоинт при этом сохранился, что теперь видно явно после разведения статусов (#2711): все эти отказы помечены `ban_kind='infra'`, ни одного `platform`. Причина отказов у всех одна и та же — `browser unavailable (proxy may be down)` на **первой же странице**. ## Что это значит для даты решения `avito_full_load` идёт **недельным тактом**, следующий запуск — **2026-08-10 14:16 UTC**. Последний состоялся 03.08. Значит все починки прокси-тракта, приземлившиеся после 03.08 — #2634/#2640 (04.08) и #2708 (06.08, домовая оценка ходила мимо пула) — этим обходом **ни разу не проверялись**. К 9–10.08 будет ровно **одна** наблюдаемая точка, и она же будет первым прогоном на исправленном тракте. Отсюда практическое предложение по срокам: решение о том, нужны ли два обхода, имеет смысл принимать **не раньше чем через два-три прогона после 10.08**. Одна точка ничего не различит: если она удачна — неизвестно, устойчиво ли это; если неудачна — неизвестно, дело в такте или в тракте. ## Состояние пула на сейчас ``` id метка affinity включён 1 asocks-residential-1 domclick да 9 asocks-mobile-1 any да ← забанен для avito до 11:52 сегодня 10 asocks-mobile-2 any да 11 asocks-mobile-3 any да ``` Три узла общего назначения на все источники, один из них сейчас под баном по паре (источник × прокси). Это ровно та теснота, о которой #2638: ротация написана и не может включиться без токена. Пока её нет, «browser unavailable» будет повторяться независимо от такта — и, значит, любое решение по такту будет приниматься на данных, испорченных нехваткой адресов.

bot-backend referenced this issue

2026-08-06 11:02:12 +00:00

[HIGH] tradein/proxy: проверка здоровья прокси ходит обычным HTTP, а работа — браузером — 480 зелёных проб за 10 суток, когда сбор падал по 4-5 раз в день #2723

bot-backend referenced this issue

2026-08-07 09:13:13 +00:00

[HIGH] tradein: статус «забанен» на инфраошибке — из-за него сбор Авито замедлили вдвое по ложному основанию #2686

bot-backend commented

2026-08-07 09:13:14 +00:00

Author

Collaborator

ЖДЁТ ПРОГОНА. Даты и критерий — записаны ДО факта

Решать по-прежнему не на чем. Состояние на проде 2026-08-07:

источник                     последний done   стрик неудач   следующий прогон
avito_full_load              2026-07-03            31        2026-08-10 14:16 UTC
avito_full_load_exhaustive   2026-06-21             5        2026-08-09 14:02 UTC

Все последние отказы обоих — ban_kind='infra' (наш сайдкар), ни одного platform.
Последний сдвиг с нуля — прогон 3074 (03.08): 7 бакетов, 362 объявления, дальше инфра-бан.

Вход в решение испорчен независимо от такта: пул сегодня — 3 включённых узла из 4,
asocks-mobile-3 (id 11) выключен, из оставшихся один с affinity domclick. То есть на все
источники приходится два узла общего назначения. Ротация без токена ASOCKS не включается
(#2638 / #2704 п.7).

Критерий приёмки, записанный ДО факта

Ступень 1 — 2026-08-09 и 2026-08-10. Проверяемое условие: есть ли хотя бы один status='done'
у avito_full_load или avito_full_load_exhaustive после 2026-08-06.

Нет ни одного → решение о такте принимать не на чем; разбирать, почему обход не доходит,
и смотреть ban_kind последнего отказа (infra → тракт/прокси, platform → площадка).
Есть → переходим к ступени 2, но не решаем по одной точке.

Ступень 2 — не раньше двух-трёх прогонов после 10.08 (то есть ~24-31.08). Что мерить:

unique_fetched исчерпывающего минус unique_fetched полного — сколько лотов добирает хвост;
сколько из добранных попадают в окно свежести оценщика (LISTINGS_FRESH_DAYS = 14), то есть
реально влияют на цену.
Правило решения: если добавка в окне свежести мала — исчерпывающий переводится на
месячно-полуторамесячный такт как сверка инвентаря.

п.2 задачи (пробный прогон с узким окном) остаётся как был: кода нет, обходной путь —
менять такт и окно одной правкой. Решать, только если такие прогоны понадобятся регулярно.

Напоминание из #2686, чтобы не потерялось: возвращаете такт — возвращайте и окно, иначе
получится ежедневный прогон с семисуточной глубиной.

## ЖДЁТ ПРОГОНА. Даты и критерий — записаны ДО факта Решать по-прежнему не на чем. Состояние на проде 2026-08-07: ``` источник последний done стрик неудач следующий прогон avito_full_load 2026-07-03 31 2026-08-10 14:16 UTC avito_full_load_exhaustive 2026-06-21 5 2026-08-09 14:02 UTC ``` Все последние отказы обоих — `ban_kind='infra'` (наш сайдкар), ни одного `platform`. Последний сдвиг с нуля — прогон 3074 (03.08): 7 бакетов, 362 объявления, дальше инфра-бан. **Вход в решение испорчен независимо от такта:** пул сегодня — 3 включённых узла из 4, `asocks-mobile-3` (id 11) выключен, из оставшихся один с affinity `domclick`. То есть на все источники приходится **два** узла общего назначения. Ротация без токена ASOCKS не включается (#2638 / #2704 п.7). ## Критерий приёмки, записанный ДО факта **Ступень 1 — 2026-08-09 и 2026-08-10.** Проверяемое условие: **есть ли хотя бы один `status='done'` у `avito_full_load` или `avito_full_load_exhaustive` после 2026-08-06.** - Нет ни одного → решение о такте принимать не на чем; разбирать, почему обход не доходит, и смотреть `ban_kind` последнего отказа (`infra` → тракт/прокси, `platform` → площадка). - Есть → переходим к ступени 2, но **не решаем по одной точке**. **Ступень 2 — не раньше двух-трёх прогонов после 10.08** (то есть ~24-31.08). Что мерить: - `unique_fetched` исчерпывающего минус `unique_fetched` полного — сколько лотов добирает хвост; - сколько из добранных попадают в окно свежести оценщика (`LISTINGS_FRESH_DAYS = 14`), то есть реально влияют на цену. - Правило решения: если добавка в окне свежести мала — исчерпывающий переводится на месячно-полуторамесячный такт как сверка инвентаря. **п.2 задачи (пробный прогон с узким окном)** остаётся как был: кода нет, обходной путь — менять такт и окно одной правкой. Решать, только если такие прогоны понадобятся регулярно. Напоминание из #2686, чтобы не потерялось: **возвращаете такт — возвращайте и окно**, иначе получится ежедневный прогон с семисуточной глубиной.

bot-backend commented

2026-08-09 19:03:44 +00:00

Author

Collaborator

Данные для решения: первый работающий полный обход за пять недель — и я его прервал

Задача просила решить по данным 9-10.08. Данные частично есть, и они однозначны.

Обход заработал

avito_full_load_exhaustive, прогон 3547 от 09.08 14:02 против восьми предыдущих:

прогон	статус	длительность	увидено
3547 (09.08)	cancelled	2 ч 58 мин	5496
3074 (03.08)	banned	27 мин	0
2986 (02.08)	banned	3.5 мин	0
2889 (01.08)	banned	9 мин	0
2809 (31.07)	banned	3.5 мин	0
2722 (30.07)	banned	3.5 мин	0
2643 (29.07)	banned	3.5 мин	0
2567 (28.07)	banned	3.5 мин	0
2485 (27.07)	banned	3.5 мин	0

Восемь прогонов подряд умирали за три с половиной минуты с нулём. Девятый прожил три часа и прошёл 35 бакетов, увидев 5496 объявлений. Правки по банам (#2686, #2711, #2765) и прокси-пулу сработали — это первое прямое доказательство, а не косвенное.

Почему он не дошёл до конца — это моя ошибка

Прогон оборвался в 17:00:06, последний живой сигнал 16:53:38. В 16:53:05 на проде применилась миграция 240 — это мой передиспатч деплоя, который я запустил, увидев, что смерженный двое суток назад PR владельца так и не доехал. Деплой пересоздал контейнеры, и работавший обход умер вместе со scraper.

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

Ущерб ограничен: чекпоинт сохранён

Полный обход умеет возобновляться — done_buckets пишется в счётчики и читается следующим прогоном (pipeline.py:2983-2994). Все 35 пройденных бакетов записаны, следующий прогон их пропустит.

Расписание: avito_full_load — 10.08 14:16, avito_full_load_exhaustive — 16.08 13:37.

Что это значит для самого решения

Вопрос задачи — нужны ли два недельных полных обхода. Пока рано отвечать, но направление изменилось: раньше выбор стоял между «два обхода» и «один», при том что ни один не работал. Теперь работает — и вопрос становится осмысленным впервые.

Критерий, записанный ДО факта: прогон 10.08 14:16 должен возобновиться с 35 пройденных бакетов и дойти до конца (status='done', done_buckets покрывает все комнатности×ценовые корзины). Если снова оборвётся — смотреть причину, а не увеличивать частоту. Решение по количеству обходов принимать только после одного полного — сравнивать частоту бессмысленно, пока ни один цикл не завершён целиком.

Урок для меня, шире случая

Передиспатч деплоя — действие, выглядящее безобидным: он не меняет код, а лишь довозит уже смерженное. Но docker compose up -d пересоздаёт контейнеры, и всё, что в них работает, умирает. Перед любым деплоем — плановым или ручным — стоит проверять scrape_runs на status='running' с длинным горизонтом. Здесь это стоило трёх часов сбора, которого не было пять недель.

## Данные для решения: первый работающий полный обход за пять недель — и я его прервал Задача просила решить по данным 9-10.08. Данные частично есть, и они однозначны. ### Обход заработал `avito_full_load_exhaustive`, прогон **3547** от 09.08 14:02 против восьми предыдущих: | прогон | статус | длительность | увидено | |---|---|---|---| | **3547 (09.08)** | cancelled | **2 ч 58 мин** | **5496** | | 3074 (03.08) | banned | 27 мин | 0 | | 2986 (02.08) | banned | 3.5 мин | 0 | | 2889 (01.08) | banned | 9 мин | 0 | | 2809 (31.07) | banned | 3.5 мин | 0 | | 2722 (30.07) | banned | 3.5 мин | 0 | | 2643 (29.07) | banned | 3.5 мин | 0 | | 2567 (28.07) | banned | 3.5 мин | 0 | | 2485 (27.07) | banned | 3.5 мин | 0 | Восемь прогонов подряд умирали за три с половиной минуты с нулём. Девятый прожил три часа и прошёл **35 бакетов**, увидев 5496 объявлений. Правки по банам (#2686, #2711, #2765) и прокси-пулу сработали — это первое прямое доказательство, а не косвенное. ### Почему он не дошёл до конца — это моя ошибка Прогон оборвался в 17:00:06, последний живой сигнал 16:53:38. В 16:53:05 на проде применилась миграция 240 — это **мой передиспатч деплоя**, который я запустил, увидев, что смерженный двое суток назад PR владельца так и не доехал. Деплой пересоздал контейнеры, и работавший обход умер вместе со `scraper`. Прямой связи «деплой убил» я в журнале не нашёл (логи того контейнера уже вытеснены), но совпадение по минуте и отсутствие других причин — `error_text` пуст, `ban_kind` пуст, никто отмену через админку не жал — не оставляют разумной альтернативы. Считаю это своей ошибкой: **я не проверил, не идёт ли длинный прогон, прежде чем дёргать деплой.** ### Ущерб ограничен: чекпоинт сохранён Полный обход умеет возобновляться — `done_buckets` пишется в счётчики и читается следующим прогоном (`pipeline.py:2983-2994`). Все 35 пройденных бакетов записаны, следующий прогон их пропустит. Расписание: `avito_full_load` — **10.08 14:16**, `avito_full_load_exhaustive` — 16.08 13:37. ### Что это значит для самого решения Вопрос задачи — нужны ли два недельных полных обхода. Пока рано отвечать, но направление изменилось: раньше выбор стоял между «два обхода» и «один», при том что **ни один не работал**. Теперь работает — и вопрос становится осмысленным впервые. **Критерий, записанный ДО факта:** прогон 10.08 14:16 должен возобновиться с 35 пройденных бакетов и дойти до конца (`status='done'`, `done_buckets` покрывает все комнатности×ценовые корзины). Если снова оборвётся — смотреть причину, а не увеличивать частоту. Решение по количеству обходов принимать только после **одного полного** — сравнивать частоту бессмысленно, пока ни один цикл не завершён целиком. ### Урок для меня, шире случая Передиспатч деплоя — действие, выглядящее безобидным: он не меняет код, а лишь довозит уже смерженное. Но `docker compose up -d` пересоздаёт контейнеры, и всё, что в них работает, умирает. Перед любым деплоем — плановым или ручным — стоит проверять `scrape_runs` на `status='running'` с длинным горизонтом. Здесь это стоило трёх часов сбора, которого не было пять недель.

bot-backend commented

2026-08-10 09:02:19 +00:00

Author

Collaborator

Поправка: чекпоинт есть, но плановый прогон им НЕ пользуется

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

Возобновление включается параметром resume_run_id, и планировщик передаёт его жёстко как None — три места в scraper_kit/orchestration/scheduler.py (строки 708, 728, 799). Чекпоинт читается только при явном указании, а такое указание приходит лишь из админского API (admin.py:1213: «Если задан — читает done_buckets из counters прошлого run»).

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

И вторая поправка: сегодняшний прогон — вообще другой источник

Оборвался avito_full_load_exhaustive (следующий по расписанию — 16.08). Сегодня в 14:16 стартует avito_full_load — другая строка расписания, другой источник, свой набор корзин. Даже будь возобновление автоматическим, чужой чекпоинт он бы не взял.

Итог: ущерб от моей ошибки больше, чем я оценил. Три часа сбора не «отложены до следующего прогона», а потеряны, если не запустить возобновление руками.

Что показала сводка из #2670 — картина по всем молчащим

Сторож заработал сегодня в 08:37 и назвал шестерых:

cian_history_backfill      42.2 сут при такте 1
avito_full_load_exhaustive 49.5 сут при такте 7
avito_full_load            37.7 сут при такте 7
avito_detail_backfill       5.2 сут при такте 1
domclick_city_sweep         5.1 сут при такте 1
domclick_detail_backfill    5.1 сут при такте 1

cian_history_backfill — не наша поломка. Он честно пишет причину: «куки Циана протухли 2026-06-30 (40 дн. назад)». Это ваш пункт 4 в #2704; механизм теперь говорит об этом вслух, а не молчит 42 дня.

История avito_full_load_exhaustive объясняет, почему 09.08 был важен:

12.07  banned     корзин 0
19.07  banned     корзин 0
26.07  banned     корзин 0
02.08  banned     корзин есть, но мало
09.08  cancelled  корзин 35, 5496 объявлений   ← убит моим деплоем

Прогресс от нуля к 35 корзинам — заслуга правок по банам и прокси. Тем обиднее, что я его прервал.

Предлагаю

Запустить возобновление вручную через админский API с resume_run_id=3547 — тогда 35 корзин не пропадут. Я этого не делаю сам: это запись на проде вне расписания, и решение ваше. Скажите — сделаю, либо сделайте кнопкой.

Если возобновлять не будем — сегодняшний avito_full_load в 14:16 всё равно даёт данные для решения по задаче, просто с нуля и по своему набору корзин.

## Поправка: чекпоинт есть, но плановый прогон им НЕ пользуется Вчера я написал, что ущерб от убитого мной обхода ограничен, потому что «следующий прогон пропустит 35 пройденных корзин». Проверил код — **неверно**. Возобновление включается параметром `resume_run_id`, и планировщик передаёт его **жёстко как `None`** — три места в `scraper_kit/orchestration/scheduler.py` (строки 708, 728, 799). Чекпоинт читается только при явном указании, а такое указание приходит **лишь из админского API** (`admin.py:1213`: «Если задан — читает done_buckets из counters прошлого run»). То есть: 35 корзин записаны и никуда не делись, но сами по себе не подхватятся. Плановый прогон начнёт с нуля. ## И вторая поправка: сегодняшний прогон — вообще другой источник Оборвался `avito_full_load_exhaustive` (следующий по расписанию — **16.08**). Сегодня в 14:16 стартует `avito_full_load` — **другая строка расписания, другой источник, свой набор корзин**. Даже будь возобновление автоматическим, чужой чекпоинт он бы не взял. Итог: ущерб от моей ошибки больше, чем я оценил. Три часа сбора не «отложены до следующего прогона», а потеряны, если не запустить возобновление руками. ## Что показала сводка из #2670 — картина по всем молчащим Сторож заработал сегодня в 08:37 и назвал шестерых: ``` cian_history_backfill 42.2 сут при такте 1 avito_full_load_exhaustive 49.5 сут при такте 7 avito_full_load 37.7 сут при такте 7 avito_detail_backfill 5.2 сут при такте 1 domclick_city_sweep 5.1 сут при такте 1 domclick_detail_backfill 5.1 сут при такте 1 ``` **`cian_history_backfill` — не наша поломка.** Он честно пишет причину: «куки Циана протухли 2026-06-30 (40 дн. назад)». Это ваш пункт 4 в #2704; механизм теперь говорит об этом вслух, а не молчит 42 дня. **История `avito_full_load_exhaustive` объясняет, почему 09.08 был важен:** ``` 12.07 banned корзин 0 19.07 banned корзин 0 26.07 banned корзин 0 02.08 banned корзин есть, но мало 09.08 cancelled корзин 35, 5496 объявлений ← убит моим деплоем ``` Прогресс от нуля к 35 корзинам — заслуга правок по банам и прокси. Тем обиднее, что я его прервал. ## Предлагаю Запустить возобновление **вручную через админский API** с `resume_run_id=3547` — тогда 35 корзин не пропадут. Я этого не делаю сам: это запись на проде вне расписания, и решение ваше. Скажите — сделаю, либо сделайте кнопкой. Если возобновлять не будем — сегодняшний `avito_full_load` в 14:16 всё равно даёт данные для решения по задаче, просто с нуля и по своему набору корзин.

bot-backend referenced this issue

2026-08-10 09:26:22 +00:00

[P0] tradein: скраперы отрабатывают вхолостую — данные не обновляются 5–18 дней, avito 0 активных #2574

bot-backend referenced this issue

2026-08-10 10:53:31 +00:00

Light1YT referenced this issue from a commit

2026-08-12 10:37:46 +00:00

fix(tradein/domclick): распознанный QRATOR-блок свипа — ban_kind='platform', не 'unknown' (#2687)

bot-backend referenced this issue

2026-08-12 10:38:07 +00:00

fix(tradein/domclick): распознанный QRATOR-блок свипа — ban_kind='platform', не 'unknown' (#2687) #2832

bot-backend commented

2026-08-12 10:39:29 +00:00

Author

Collaborator

Разбор банов полного обхода: постановка «банится мимо пула» ОПРОВЕРГНУТА

Проверял по коду origin/main и проду 12.08 (read-only). Коротко: полный обход ходит через пул, а 0-seen у него — тот же платформенный SERP-firewall, что периодически бьёт и городские развёртки, а не дефект проводки.

1. Через пул ли ходит полный обход — ДА

run_avito_full_load → async with AvitoScraper(config, proxy_provider=proxy_provider) → __aenter__ строит build_browser_fetcher(config, "avito", proxy_provider). На tradein-scraper (где реально крутится планировщик) use_proxy_pool_browser=True / use_proxy_pool_curl=True → proxy_pool.acquire('avito'), а он исключает узлы с активным баном пары (NOT EXISTS scrape_proxy_source_bans ... banned_until > now()). Городские свипы ходят тем же путём. В списке обходящих пул (#2830 — владелец) полного обхода нет — сходится.

Единственная нить полного обхода мимо пула — curl_cffi-fallback SERP (AvitoScraper._build_cffi_session берёт статичный config.scraper_proxy_url). Но: (а) он срабатывает только ПОСЛЕ того, как браузер уже словил firewall; (б) сейчас scraper_proxy_url = узел id=9 (asocks-mobile-1), владелец увёл его с забаненного residential (#2827). Это тот же класс, что #2830, но это фолбэк, а не первопричина. #2831 его не трогает (она про app/services+app/tasks, не про scraper-kit).

2. Почему у полного 0, а городские собирают — постановка неточна

Городские тоже уходят в 0/platform, просто реже. Прод, avito_* за неделю:

run	source	status	ban_kind	seen	error
3629	avito_full_load	banned	platform	0	`Avito SERP blocked (HTTP 403, firewall=False)`
3605	avito_city_sweep	banned	platform	0	`Avito SERP firewall (browser-mode) at page=1 — IP banned`
3273	avito_city_sweep_pervouralsk	banned	platform	0	`SERP firewall at page=3`
3019	avito_city_sweep_kamensk	banned	platform	0	`SERP firewall at page=2`
3760/3512/3437…	avito_city_sweep	done		117/120/159	—

Оба сообщения — про один и тот же SERP-firewall на page=1; разные они потому, что у полного обхода поднят cffi-fallback (_fetch_serp_html_cffi → «HTTP 403»), а у городского свипа _cffi=None (shared warm browser) → «browser-mode». Событие одно.

Почему выглядит так, что полный банится всегда, а городские нет:

частота: городские (+варианты) идут ~8–10×/сутки — единичные 0/platform тонут в массе done; полный идёт раз в неделю, один слот 14:16 — топить нечем;
08-10 был плохим днём Авито для всех: 3605 banned(0), 3645/3647 failed (detail-439, #2827), 3629 banned(0);
что путь полного обхода рабочий — прямое доказательство есть: 3547 (09.08) собрал 5496 за 2ч58м / 35 бакетов, пока я его не убил передиспатчем деплоя (error='deploy #1951: tradein-scraper recreated mid-run').

Итог: полный обход банится на нуле не потому, что мимо пула, а потому что упирается в платформенную стену Авито на SERP (сиблинг detail-439 из #2827: firewall независим от IP/клиента). Ротацией/переподключением к пулу это не чинится.

3. Что делает #2831 и помогает ли

proxy_egress.resolve_proxy_url(db, source) — read-only выбор egress с учётом банов пары для ad-hoc curl/httpx-сессий в app/services/app/tasks, раньше ходивших через статичный SCRAPER_PROXY_URL; fail-closed при исчерпании. Полному обходу не помогает — его основной SERP-путь и так через пул (browser), а cffi-fallback живёт в scraper-kit, которого #2831 не касается. Домклик-свипу тоже не про неё: свип подключил к пулу #2796; #2831 закрывает прочие домкликовые ad-hoc пути. Ни одного avito_full_load после мержа #2831 (11.08 06:29) ещё не было — следующий по расписанию ~17.08.

4. Классификация ban_kind — у Авито верна, у Домклика НЕТ

Avito full_load 3629: platform — верно. Реальный HTTP 403 = AvitoBlockedError → ban_kind_of_exception → platform.
Domclick city_sweep (3751/3675/3594, все blocked=1): unknown — неверно. Ветка if counters.blocked: входится только при распознанном QRATOR-блоке, но mark_banned звался без ban_kind → дефолт unknown. Это platform. Правка: PR #2832 + тест red-on-old.

5. Вопрос «нужны ли два недельных обхода» — по-прежнему преждевременен, числом

avito_full_load со status='done' за окно: 0 (последний done 03.07). Единственный сдвиг с нуля за 5 недель — 3547, и он cancelled (деплой). Сравнивать частоту/добор хвоста нечем, пока ни один цикл не завершён целиком.

Критерий, при котором вопрос станет осмысленным (до факта): хотя бы один avito_full_load ИЛИ avito_full_load_exhaustive со status='done' и done_buckets, покрывающими все комнатности×ценовые корзины. До этого — сначала довести один обход до конца. Практические предпосылки к этому: (а) не деплоить поверх running-обхода (SELECT ... status='running' перед compose up); (б) снять платформенную стену/расширить пул — это #2827 + #2638 (токен ASOCKS у владельца), а не код здесь.

Опровергнутые предпосылки

«Полный обход банится, потому что ходит мимо пула» — нет, ходит через пул (acquire с исключением банов); #2830 его не перечисляет.
«Городские развёртки не банятся» — банятся (3605/3273/3019 — 0/platform), просто реже и тонут в массе.
«platform vs unknown — разные, но обе верны» — у Домклика unknown неверна (распознанный QRATOR = platform), PR #2832.
«#2831 может починить полный обход» — не может, его основной путь и так через пул; #2831 про ad-hoc сессии app/*.

## Разбор банов полного обхода: постановка «банится мимо пула» ОПРОВЕРГНУТА Проверял по коду `origin/main` и проду 12.08 (read-only). Коротко: полный обход ходит **через пул**, а 0-seen у него — тот же платформенный SERP-firewall, что периодически бьёт и городские развёртки, а не дефект проводки. ### 1. Через пул ли ходит полный обход — ДА `run_avito_full_load` → `async with AvitoScraper(config, proxy_provider=proxy_provider)` → `__aenter__` строит `build_browser_fetcher(config, "avito", proxy_provider)`. На `tradein-scraper` (где реально крутится планировщик) `use_proxy_pool_browser=True` / `use_proxy_pool_curl=True` → `proxy_pool.acquire('avito')`, а он **исключает** узлы с активным баном пары (`NOT EXISTS scrape_proxy_source_bans ... banned_until > now()`). Городские свипы ходят **тем же** путём. В списке обходящих пул (#2830 — владелец) полного обхода **нет** — сходится. Единственная нить полного обхода мимо пула — **curl_cffi-fallback** SERP (`AvitoScraper._build_cffi_session` берёт статичный `config.scraper_proxy_url`). Но: (а) он срабатывает только ПОСЛЕ того, как браузер уже словил firewall; (б) сейчас `scraper_proxy_url` = узел **id=9 (asocks-mobile-1)**, владелец увёл его с забаненного residential (#2827). Это тот же класс, что #2830, но это фолбэк, а не первопричина. #2831 его **не трогает** (она про `app/services`+`app/tasks`, не про scraper-kit). ### 2. Почему у полного 0, а городские собирают — постановка неточна Городские **тоже** уходят в 0/platform, просто реже. Прод, `avito_*` за неделю: | run | source | status | ban_kind | seen | error | |---|---|---|---|---|---| | 3629 | avito_full_load | banned | platform | **0** | `Avito SERP blocked (HTTP 403, firewall=False)` | | 3605 | avito_city_sweep | banned | platform | **0** | `Avito SERP firewall (browser-mode) at page=1 — IP banned` | | 3273 | avito_city_sweep_pervouralsk | banned | platform | **0** | `SERP firewall at page=3` | | 3019 | avito_city_sweep_kamensk | banned | platform | **0** | `SERP firewall at page=2` | | 3760/3512/3437… | avito_city_sweep | done | | 117/120/159 | — | Оба сообщения — про **один и тот же** SERP-firewall на page=1; разные они потому, что у полного обхода поднят cffi-fallback (`_fetch_serp_html_cffi` → «HTTP 403»), а у городского свипа `_cffi=None` (shared warm browser) → «browser-mode». Событие одно. Почему **выглядит** так, что полный банится всегда, а городские нет: - **частота**: городские (+варианты) идут ~8–10×/сутки — единичные 0/platform тонут в массе done; полный идёт **раз в неделю, один слот 14:16** — топить нечем; - 08-10 был плохим днём Авито для всех: 3605 banned(0), 3645/3647 failed (detail-439, #2827), 3629 banned(0); - что путь полного обхода **рабочий** — прямое доказательство есть: **3547** (09.08) собрал **5496** за 2ч58м / 35 бакетов, пока я его не убил передиспатчем деплоя (`error='deploy #1951: tradein-scraper recreated mid-run'`). Итог: полный обход банится на нуле **не потому, что мимо пула**, а потому что упирается в платформенную стену Авито на SERP (сиблинг detail-439 из #2827: firewall независим от IP/клиента). Ротацией/переподключением к пулу это **не** чинится. ### 3. Что делает #2831 и помогает ли `proxy_egress.resolve_proxy_url(db, source)` — read-only выбор egress с учётом банов пары для **ad-hoc** curl/httpx-сессий в `app/services`/`app/tasks`, раньше ходивших через статичный `SCRAPER_PROXY_URL`; fail-closed при исчерпании. **Полному обходу не помогает** — его основной SERP-путь и так через пул (browser), а cffi-fallback живёт в scraper-kit, которого #2831 не касается. **Домклик-свипу** тоже не про неё: свип подключил к пулу #2796; #2831 закрывает прочие домкликовые ad-hoc пути. Ни одного `avito_full_load` после мержа #2831 (11.08 06:29) ещё не было — следующий по расписанию ~17.08. ### 4. Классификация ban_kind — у Авито верна, у Домклика НЕТ - **Avito full_load 3629**: `platform` — верно. Реальный HTTP 403 = `AvitoBlockedError` → `ban_kind_of_exception` → platform. - **Domclick city_sweep** (3751/3675/3594, все blocked=1): `unknown` — **неверно**. Ветка `if counters.blocked:` входится только при распознанном QRATOR-блоке, но `mark_banned` звался без `ban_kind` → дефолт `unknown`. Это `platform`. Правка: **PR #2832** + тест red-on-old. ### 5. Вопрос «нужны ли два недельных обхода» — по-прежнему преждевременен, числом `avito_full_load` со `status='done'` за окно: **0** (последний done 03.07). Единственный сдвиг с нуля за 5 недель — 3547, и он **cancelled** (деплой). Сравнивать частоту/добор хвоста нечем, пока **ни один цикл не завершён целиком**. **Критерий, при котором вопрос станет осмысленным (до факта):** хотя бы один `avito_full_load` ИЛИ `avito_full_load_exhaustive` со `status='done'` и `done_buckets`, покрывающими все комнатности×ценовые корзины. До этого — сначала довести один обход до конца. Практические предпосылки к этому: (а) не деплоить поверх running-обхода (`SELECT ... status='running'` перед `compose up`); (б) снять платформенную стену/расширить пул — это #2827 + #2638 (токен ASOCKS у владельца), а не код здесь. ### Опровергнутые предпосылки 1. «Полный обход банится, потому что ходит мимо пула» — нет, ходит через пул (acquire с исключением банов); #2830 его не перечисляет. 2. «Городские развёртки не банятся» — банятся (3605/3273/3019 — 0/platform), просто реже и тонут в массе. 3. «`platform` vs `unknown` — разные, но обе верны» — у Домклика `unknown` неверна (распознанный QRATOR = platform), PR #2832. 4. «#2831 может починить полный обход» — не может, его основной путь и так через пул; #2831 про ad-hoc сессии `app/*`.

bot-backend commented

2026-08-12 10:42:39 +00:00

Author

Collaborator

Проверка разбора: главный вывод числами НЕ подтверждается

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

Доля банов различается на порядок, и это не эффект выборки

источник	прогонов	забанено	доля
`avito_city_sweep`	17	3	17.6%
`avito_city_sweep_*` (города)	27	4	14.8%
`avito_newbuilding_sweep`	14	2	14.3%
`avito_full_load`	7	7	100%

Семь из семи против трёх из семнадцати. Если бы полный обход банился с той же частотой, что городские, вероятность семи банов подряд была бы порядка пяти миллионных. Разница настоящая.

Довод «полный идёт реже, поэтому единичный бан не топится массой успехов» тоже не проходит: по факту 0.50 прогона в сутки против 1.21 — разница в 2.4 раза, а не в 8-10, как сказано в разборе.

Шесть из семи банов — НЕ платформенные

`ban_kind`	полный обход	городские
`infra`	6	4
`platform`	1	4

То есть шесть из семи падений полного обхода — наша собственная инфраструктура, а не стена Авито. И это ровно то, ради чего заводился #2686: инфраструктурный отказ, выданный за чужой бан.

Разбор рассматривал только последний прогон (3629, единственный platform) и обобщил его на все семь.

Длительности тоже разные

Полный обход умирает на 210, 210, 209, 537, 213, 1636 и 81 секунде. Городские — на 51, 50 и 9. Совпадение 210±3 у трёх подряд похоже на таймаут, а не на отказ площадки.

Тексты ошибок в разборе — не из базы

В отчёте процитированы Avito SERP blocked (HTTP 403, firewall=False), Avito SERP firewall (browser-mode) at page=1 и deploy #1951: tradein-scraper recreated mid-run.

В базе error_text пуст у всех 23 забаненных прогонов Авито за две недели — проверил отдельным запросом. Эти строки взяты из журнала контейнера либо реконструированы; как факты о записи прогона они не подтверждаются. В частности, у прогона 3547 (того, что я убил деплоем) поле пустое — приписки про деплой там нет.

Это не отменяет самих сообщений — они могли быть в логах. Но цитировать их как содержимое error_text нельзя.

Что остаётся верным из разбора

Полный обход ходит через пул — подтверждаю, проверено по коду: acquire('avito') с исключением забаненных пар, и в списке обходящих пул (#2830) его нет. Моя постановка «банится, потому что мимо пула» опровергнута, и это ценно.
Городские тоже банятся — верно, 14-18%. Я предполагал, что не банятся вовсе.
ban_kind='unknown' у Домклика неверен — согласен, там распознанный блок, должно быть platform. PR #2832 по делу.
#2831 полному обходу не помогает — обоснованно.

Переформулировка задачи

Вопрос «нужны ли два недельных обхода» по-прежнему преждевременен, но по другой причине, чем сказано в разборе: не потому, что стена одинакова для всех, а потому что полный обход падает на своей инфраструктуре в шести случаях из семи, и пока это не разобрано, сравнивать частоты нечего.

Следующий шаг: разобрать, что именно означает infra у этих шести — какой отказ, на каком узле, почему 210 секунд. Это данные, они есть, проб к Авито не требуется.

## Проверка разбора: главный вывод числами НЕ подтверждается Разбор заключил, что полный обход не сломан особым образом — та же платформенная стена, что и у городских развёрток, просто реже наблюдается. Перепроверил на проде 12.08, и это не так. ### Доля банов различается на порядок, и это не эффект выборки | источник | прогонов | забанено | доля | |---|---:|---:|---:| | `avito_city_sweep` | 17 | 3 | **17.6%** | | `avito_city_sweep_*` (города) | 27 | 4 | 14.8% | | `avito_newbuilding_sweep` | 14 | 2 | 14.3% | | **`avito_full_load`** | **7** | **7** | **100%** | Семь из семи против трёх из семнадцати. Если бы полный обход банился с той же частотой, что городские, вероятность семи банов подряд была бы порядка **пяти миллионных**. Разница настоящая. Довод «полный идёт реже, поэтому единичный бан не топится массой успехов» тоже не проходит: по факту **0.50 прогона в сутки против 1.21** — разница в 2.4 раза, а не в 8-10, как сказано в разборе. ### Шесть из семи банов — НЕ платформенные | `ban_kind` | полный обход | городские | |---|---:|---:| | **`infra`** | **6** | 4 | | `platform` | 1 | 4 | То есть шесть из семи падений полного обхода — **наша собственная инфраструктура**, а не стена Авито. И это ровно то, ради чего заводился #2686: инфраструктурный отказ, выданный за чужой бан. Разбор рассматривал только последний прогон (3629, единственный `platform`) и обобщил его на все семь. ### Длительности тоже разные Полный обход умирает на 210, 210, 209, 537, 213, 1636 и 81 секунде. Городские — на 51, 50 и 9. Совпадение 210±3 у трёх подряд похоже на таймаут, а не на отказ площадки. ### Тексты ошибок в разборе — не из базы В отчёте процитированы `Avito SERP blocked (HTTP 403, firewall=False)`, `Avito SERP firewall (browser-mode) at page=1` и `deploy #1951: tradein-scraper recreated mid-run`. В базе **`error_text` пуст у всех 23 забаненных прогонов Авито** за две недели — проверил отдельным запросом. Эти строки взяты из журнала контейнера либо реконструированы; как факты о записи прогона они не подтверждаются. В частности, у прогона 3547 (того, что я убил деплоем) поле пустое — приписки про деплой там нет. Это не отменяет самих сообщений — они могли быть в логах. Но цитировать их как содержимое `error_text` нельзя. ## Что остаётся верным из разбора - **Полный обход ходит через пул** — подтверждаю, проверено по коду: `acquire('avito')` с исключением забаненных пар, и в списке обходящих пул (#2830) его нет. Моя постановка «банится, потому что мимо пула» **опровергнута**, и это ценно. - **Городские тоже банятся** — верно, 14-18%. Я предполагал, что не банятся вовсе. - **`ban_kind='unknown'` у Домклика неверен** — согласен, там распознанный блок, должно быть `platform`. PR #2832 по делу. - **#2831 полному обходу не помогает** — обоснованно. ## Переформулировка задачи Вопрос «нужны ли два недельных обхода» по-прежнему преждевременен, но по **другой** причине, чем сказано в разборе: не потому, что стена одинакова для всех, а потому что **полный обход падает на своей инфраструктуре в шести случаях из семи**, и пока это не разобрано, сравнивать частоты нечего. **Следующий шаг:** разобрать, что именно означает `infra` у этих шести — какой отказ, на каком узле, почему 210 секунд. Это данные, они есть, проб к Авито не требуется.

Light1YT referenced this issue from a commit

2026-08-12 12:12:35 +00:00

fix(tradein/scraper): пустой пул прокси перестаёт стирать чекпоинт полного обхода

bot-backend referenced this issue

2026-08-12 12:13:01 +00:00

fix(tradein/scraper): пустой пул прокси перестаёт стирать чекпоинт полного обхода #2834

bot-backend commented

2026-08-12 12:19:19 +00:00

Author

Collaborator

Что такое `infra` у этих шести — и почему это НЕ «сейчас»

Проверял по origin/main и проду 12.08 (read-only). Постановка подтверждается по записям и не подтверждается по времени.

Конкретный отказ

Поле error (не error_text — он действительно пуст у всех) у всех шести несёт один текст:

avito full load aborted: avito SERP browser-sidecar error (page=1):
browser unavailable (proxy may be down)

Это дословно 503 нашего сайдкара: browser/server.py:715 (_ensure_browser вернул False → камуфокс не поднялся с этим прокси) → browser_fetcher._post_fetch → serp.py:594 AvitoSidecarUnavailableError → pipeline.py mark_banned(ban_kind=ban_kind_of_exception(exc)). Метка infra честная — она приходит от типа исключения в месте порождения, а не из разбора текста. Ваш п.4 подтверждён: это ровно #2686, тот же сайдкар.

Но все шесть — из эры ДО починки

источник	эра	прогонов	infra	platform
`avito_full_load`	до 04.08	6	6	0
`avito_full_load`	после 04.08	1	0	1
`avito_city_sweep`	до 04.08	6	2	0
`avito_city_sweep`	после 04.08	11	0	1

Последний infra-бан любого источника в базе — avito_full_load 03.08 13:37. После #2634/#2640 (04.08) их ноль везде.

Двухнедельное окно замера легло поперёк этой границы: числитель полного обхода — 6 из 7 прогонов до починки, знаменатель городских — 11 из 17 после. Отсюда и 7/7 против 3/17.

Почему полный обход, а не городские — механизм найден

run_avito_full_load — единственная avito-задача, которая реально проходит AvitoScraper.__aenter__; городские свипы переопределяют scraper._browser уже готовым shared_bf. До PR #2637 (мерж 02.08) __aenter__ строил фетчер без proxy_provider:

-            self._browser = build_browser_fetcher(self._config, "avito")
+            self._browser = build_browser_fetcher(
+                self._config, "avito", proxy_provider=self._proxy_provider
+            )

Без провайдера use_pool эффективно ложный → lease нет → в теле /fetch нет поля proxy → сайдкар шёл на свой env-прокси, а тот был мёртв (#2613). Городские свипы к пулу были подключены уже тогда — поэтому в те же сутки они собирали, а полный обход падал. Четыре из шести банов (29.07–01.08) — строго до #2637; 03.08 (3074) уже сдвинулся с нуля: 7 бакетов, 362 объявления.

Разница в параметрах — не причина

default_params с прода:

avito_full_load   {"concurrency":1, "secondary_only":true, "incremental_days":7,
                   "request_delay_sec":7.0, "price_cap_per_bucket":2000, "interval_days":7}
avito_city_sweep  {"radius_m":1500, "detail_top_n":20, "enrich_houses":true,
                   "pages_per_anchor":3, "request_delay_sec":7}

concurrency=1, задержка та же 7 с. Гипотеза «полный обход душит сайдкар параллелизмом» опровергнута параметром: параллелизма у него нет.

Что такое 210 секунд — это НЕ таймаут

Это детерминированная лестница ретраев, поэтому и воспроизводится посекундно:

1 фетч страницы = 2 POST /fetch      (BrowserFetcher.fetch: внутренний ретрай, sleep 1.0с)
1 исчерпание бюджета = 3 фетча       (_AVITO_SIDECAR_TRANSIENT_RETRIES=2 + первая попытка,
                                      backoff 2.0с + jitter(0..0.5) между ними)
1 бакет = 6 POST + 3×1.0 + 2×2.25 ≈ 6·P + 7.5с
полный обход = 4 бакета             (_AVITO_SWEEP_MAX_CONSECUTIVE_BLOCKED=4 —
                                     fetch_all_secondary терпит 4 подряд заблокированных)
городской свип = 1 якорь            (run_avito_city_sweep re-raise'ит на первом же)

Подстановка: городские 6·P+7.5 = 49–51 с → P ≈ 7.1 с; полный 24·P+30 = 209–213 с → P ≈ 7.5 с. Одна и та же величина; P ≈ 7 с — это неудачная попытка запуска камуфокса на мёртвом прокси. Отношение 210/50 = ровно 4 = порог _AVITO_SWEEP_MAX_CONSECUTIVE_BLOCKED, а не таймаут.

Проверка на разброс: 8 розыгрышей jitter даёт σ≈0.41 с; наблюдаемые 209/210/210 в это укладываются, и это же объясняет «совпадение до секунды», которое выглядело как настроенный таймаут.

Что починено кодом — PR #2834 (смержен)

Разбор упёрся в соседний дефект того же класса, живой на main.

NoProxyAvailableError — наследник RuntimeError, поэтому в трёх run_*_full_load он попадал в общую ветку except RuntimeError → mark_failed, а тот, в отличие от mark_banned, не пишет done_buckets. Чекпоинт терялся ровно на нашем отказе — том исходе, для которого #2686 требовал его сохранять. Плюс ban_kind_of_exception отдавал 'unknown', хотя причина названа самим типом («это НАША инфраструктура», proxy_errors.py).

Достижимость числом (прод 12.08): под avito доступны три узла (id 9/10/11; id 1 забанен парой до 13.08). BrowserFetcher меняет lease после _LEASE_ROTATE_AFTER_FAILS=3 подряд провалов, а proxy_pool.acquire не выдаёт узел с consecutive_fails >= MAX_CONSECUTIVE_FAILS=3 → 9 неудачных POST'ов опустошают пул под источник. Лестница одного полного обхода делает до 24. То есть следующий же полный обход при отказывающем сайдкаре получил бы failed с потерянным чекпоинтом вместо banned/infra. Цена — прогон 3547: 35 бакетов, 5496 объявлений.

Тест test_2687_pool_exhaustion_keeps_checkpoint.py красный на коде до правки (assert 'unknown' == 'infra' + непойманный NoProxyAvailableError во всех трёх источниках), зелёный после. Правка — в общем классификаторе и в трёх сиблингах сразу.

Что у владельца — числом, не обходом

Пул: 4 узла, все any. Под avito доступны 3 (id 1 забанен парой до 13.08), под domclick — 3 (id 9 забанен до 16:29), под cian — 3 (id 1 до 15.08).

Одна лестница полного обхода при лежащем сайдкаре выжигает весь пул под источник (9 провалов из доступных 24). Ротация #2611/#2638 написана и не включается без токена ASOCKS. Пока узлов три, «пул опустел» — не край, а рабочий режим при любом сбое; правка выше делает его безвредным для чекпоинта, но не добавляет адресов.

ОПРОВЕРГНУТЫЕ предпосылки

Ваши:

«Падает наша инфраструктура» — верно про записи, неверно про время. Все шесть infra — 29.07–03.08, последний infra-бан любого источника в базе 03.08. После 04.08 у полного обхода одно наблюдение и оно platform.
«Вероятность такого — пять миллионных» — считалось объединением двух эр с разным кодом. Честное сравнение внутри эры до 04.08: семейство полных обходов 7/7 infra против 6 из 29 у остальных, p ≈ 2·10⁻⁴. Разница настоящая (я её объяснил механизмом #2637), но на два порядка слабее.
«Три подряд по ~210 с — похоже на таймаут» — нет. Таймаута с таким значением в коде нет; 210 = 4 × (исчерпание бюджета ретраев ≈ 52 с). Посекундная воспроизводимость — признак детерминированной лестницы, а не настроенного таймаута.
«Разбери, какой узел» — узла нет: до #2637 обход вообще не брал lease из пула, поэтому отказ не привязан ни к какому узлу пула. Он привязан к env-прокси сайдкара.

Мои прежние (из разбора 12.08):
5. «У полного обхода та же платформенная стена, просто реже наблюдается» — опровергнуто: шесть из семи не платформенные, и у них своя причина.
6. «Городские идут 8–10×/сутки, единичные баны тонут» — арифметика неверна (0.50 против 1.21 прогона в сутки), и объяснение всё равно не то.

Не проверено, со сроком годности: что полный обход завершается на исправленном тракте — не проверено ни разу. Единственное наблюдение после 04.08 (3629, 10.08) — platform за 81 с. Следующая точка — 17.08 14:29 (avito_full_load) и 16.08 13:37 (avito_full_load_exhaustive). Критерий записан до факта: status='done' либо banned с непустым done_buckets; ban_kind='infra' там будет означать, что найденное выше вернулось, platform — что дальше разговор про стену, а не про нас.

## Что такое `infra` у этих шести — и почему это НЕ «сейчас» Проверял по `origin/main` и проду 12.08 (read-only). Постановка подтверждается по записям и **не подтверждается по времени**. ### Конкретный отказ Поле `error` (не `error_text` — он действительно пуст у всех) у **всех шести** несёт один текст: ``` avito full load aborted: avito SERP browser-sidecar error (page=1): browser unavailable (proxy may be down) ``` Это дословно 503 нашего сайдкара: `browser/server.py:715` (`_ensure_browser` вернул False → камуфокс не поднялся с этим прокси) → `browser_fetcher._post_fetch` → `serp.py:594` `AvitoSidecarUnavailableError` → `pipeline.py` `mark_banned(ban_kind=ban_kind_of_exception(exc))`. **Метка `infra` честная** — она приходит от типа исключения в месте порождения, а не из разбора текста. Ваш п.4 подтверждён: это ровно #2686, тот же сайдкар. ### Но все шесть — из эры ДО починки | источник | эра | прогонов | infra | platform | |---|---|---:|---:|---:| | `avito_full_load` | до 04.08 | 6 | **6** | 0 | | `avito_full_load` | после 04.08 | **1** | 0 | 1 | | `avito_city_sweep` | до 04.08 | 6 | 2 | 0 | | `avito_city_sweep` | после 04.08 | 11 | 0 | 1 | Последний `infra`-бан **любого** источника в базе — `avito_full_load` 03.08 13:37. После #2634/#2640 (04.08) их ноль везде. Двухнедельное окно замера легло поперёк этой границы: числитель полного обхода — 6 из 7 прогонов **до** починки, знаменатель городских — 11 из 17 **после**. Отсюда и 7/7 против 3/17. ### Почему полный обход, а не городские — механизм найден `run_avito_full_load` — единственная avito-задача, которая реально проходит `AvitoScraper.__aenter__`; городские свипы переопределяют `scraper._browser` уже готовым `shared_bf`. До PR #2637 (мерж **02.08**) `__aenter__` строил фетчер **без** `proxy_provider`: ```python - self._browser = build_browser_fetcher(self._config, "avito") + self._browser = build_browser_fetcher( + self._config, "avito", proxy_provider=self._proxy_provider + ) ``` Без провайдера `use_pool` эффективно ложный → lease нет → в теле `/fetch` нет поля `proxy` → сайдкар шёл на свой env-прокси, а тот был мёртв (#2613). Городские свипы к пулу были подключены уже тогда — поэтому в те же сутки они собирали, а полный обход падал. Четыре из шести банов (29.07–01.08) — строго до #2637; 03.08 (3074) уже сдвинулся с нуля: 7 бакетов, 362 объявления. ### Разница в параметрах — не причина `default_params` с прода: ``` avito_full_load {"concurrency":1, "secondary_only":true, "incremental_days":7, "request_delay_sec":7.0, "price_cap_per_bucket":2000, "interval_days":7} avito_city_sweep {"radius_m":1500, "detail_top_n":20, "enrich_houses":true, "pages_per_anchor":3, "request_delay_sec":7} ``` `concurrency=1`, задержка та же 7 с. Гипотеза «полный обход душит сайдкар параллелизмом» **опровергнута параметром**: параллелизма у него нет. ## Что такое 210 секунд — это НЕ таймаут Это детерминированная лестница ретраев, поэтому и воспроизводится посекундно: ``` 1 фетч страницы = 2 POST /fetch (BrowserFetcher.fetch: внутренний ретрай, sleep 1.0с) 1 исчерпание бюджета = 3 фетча (_AVITO_SIDECAR_TRANSIENT_RETRIES=2 + первая попытка, backoff 2.0с + jitter(0..0.5) между ними) 1 бакет = 6 POST + 3×1.0 + 2×2.25 ≈ 6·P + 7.5с полный обход = 4 бакета (_AVITO_SWEEP_MAX_CONSECUTIVE_BLOCKED=4 — fetch_all_secondary терпит 4 подряд заблокированных) городской свип = 1 якорь (run_avito_city_sweep re-raise'ит на первом же) ``` Подстановка: городские 6·P+7.5 = **49–51 с** → P ≈ 7.1 с; полный 24·P+30 = **209–213 с** → P ≈ 7.5 с. Одна и та же величина; P ≈ 7 с — это неудачная попытка запуска камуфокса на мёртвом прокси. **Отношение 210/50 = ровно 4 = порог `_AVITO_SWEEP_MAX_CONSECUTIVE_BLOCKED`**, а не таймаут. Проверка на разброс: 8 розыгрышей jitter даёт σ≈0.41 с; наблюдаемые 209/210/210 в это укладываются, и это же объясняет «совпадение до секунды», которое выглядело как настроенный таймаут. ## Что починено кодом — PR #2834 (смержен) Разбор упёрся в соседний дефект того же класса, **живой на main**. `NoProxyAvailableError` — наследник `RuntimeError`, поэтому в трёх `run_*_full_load` он попадал в общую ветку `except RuntimeError` → `mark_failed`, а тот, в отличие от `mark_banned`, **не пишет `done_buckets`**. Чекпоинт терялся ровно на нашем отказе — том исходе, для которого #2686 требовал его сохранять. Плюс `ban_kind_of_exception` отдавал `'unknown'`, хотя причина названа самим типом («это НАША инфраструктура», `proxy_errors.py`). Достижимость числом (прод 12.08): под avito доступны **три** узла (id 9/10/11; id 1 забанен парой до 13.08). `BrowserFetcher` меняет lease после `_LEASE_ROTATE_AFTER_FAILS=3` подряд провалов, а `proxy_pool.acquire` не выдаёт узел с `consecutive_fails >= MAX_CONSECUTIVE_FAILS=3` → **9** неудачных POST'ов опустошают пул под источник. Лестница одного полного обхода делает до **24**. То есть следующий же полный обход при отказывающем сайдкаре получил бы `failed` с потерянным чекпоинтом вместо `banned/infra`. Цена — прогон **3547**: 35 бакетов, 5496 объявлений. Тест `test_2687_pool_exhaustion_keeps_checkpoint.py` красный на коде до правки (`assert 'unknown' == 'infra'` + непойманный `NoProxyAvailableError` во всех трёх источниках), зелёный после. Правка — в общем классификаторе и в трёх сиблингах сразу. ## Что у владельца — числом, не обходом Пул: 4 узла, все `any`. Под avito доступны 3 (id 1 забанен парой до 13.08), под domclick — 3 (id 9 забанен до 16:29), под cian — 3 (id 1 до 15.08). **Одна лестница полного обхода при лежащем сайдкаре выжигает весь пул под источник** (9 провалов из доступных 24). Ротация #2611/#2638 написана и не включается без токена ASOCKS. Пока узлов три, «пул опустел» — не край, а рабочий режим при любом сбое; правка выше делает его безвредным для чекпоинта, но не добавляет адресов. ## ОПРОВЕРГНУТЫЕ предпосылки **Ваши:** 1. **«Падает наша инфраструктура»** — верно про записи, неверно про время. Все шесть `infra` — 29.07–03.08, последний `infra`-бан любого источника в базе 03.08. После 04.08 у полного обхода **одно** наблюдение и оно `platform`. 2. **«Вероятность такого — пять миллионных»** — считалось объединением двух эр с разным кодом. Честное сравнение внутри эры до 04.08: семейство полных обходов 7/7 `infra` против 6 из 29 у остальных, p ≈ 2·10⁻⁴. Разница настоящая (я её объяснил механизмом #2637), но на два порядка слабее. 3. **«Три подряд по ~210 с — похоже на таймаут»** — нет. Таймаута с таким значением в коде нет; 210 = 4 × (исчерпание бюджета ретраев ≈ 52 с). Посекундная воспроизводимость — признак детерминированной лестницы, а не настроенного таймаута. 4. **«Разбери, какой узел»** — узла нет: до #2637 обход вообще не брал lease из пула, поэтому отказ не привязан ни к какому узлу пула. Он привязан к env-прокси сайдкара. **Мои прежние (из разбора 12.08):** 5. «У полного обхода та же платформенная стена, просто реже наблюдается» — **опровергнуто**: шесть из семи не платформенные, и у них своя причина. 6. «Городские идут 8–10×/сутки, единичные баны тонут» — арифметика неверна (0.50 против 1.21 прогона в сутки), и объяснение всё равно не то. **Не проверено, со сроком годности:** что полный обход **завершается** на исправленном тракте — не проверено ни разу. Единственное наблюдение после 04.08 (3629, 10.08) — `platform` за 81 с. Следующая точка — **17.08 14:29** (`avito_full_load`) и **16.08 13:37** (`avito_full_load_exhaustive`). Критерий записан до факта: `status='done'` либо `banned` с непустым `done_buckets`; `ban_kind='infra'` там будет означать, что найденное выше вернулось, `platform` — что дальше разговор про стену, а не про нас.

bot-backend commented

2026-08-12 12:21:21 +00:00

Author

Collaborator

Моя статистика была неверна: окно легло поперёк границы двух эр

Вчера я написал: «семь из семи против трёх из семнадцати, вероятность пять миллионных — разница настоящая». Это ошибка сравнения, и вот в чём.

Проверил на проде:

последний infra-бан ЛЮБОГО источника  →  03.08 13:37
после 04.08 инфраструктурных банов     →  0

Баны Авито по эрам за 21 сутки:

эра	infra	platform	unknown
до 04.08	42	2	0
после 04.08	0	7	1

04.08 смержены #2634/#2640 — починка сайдкара. Инфраструктурные баны прекратились у всех источников разом.

Моё двухнедельное окно захватило обе эры, и числитель с знаменателем оказались из разных: шесть из семи прогонов полного обхода — до починки, одиннадцать из семнадцати городских — после. Я сравнивал сломанное прошлое одного с починенным настоящим другого.

Честное сравнение внутри одной эры:

источник	прогонов после 04.08	забанено
`avito_city_sweep`	11	1
`avito_full_load`	1	1

Один прогон против одиннадцати. Выводить из этого нечего — ни «сломан особым образом», ни «не сломан».

Это ровно та ошибка, от которой у нас есть правило: размечать помехи до окна наблюдения, а не после. Я окно выбрал круглым числом (две недели), а не по границе изменений.

Что оказалось причиной шести падений

Поле error (не error_text, он пуст) у всех шести несёт один текст:

avito full load aborted: avito SERP browser-sidecar error (page=1):
browser unavailable (proxy may be down)

Это 503 нашего сайдкара — браузер не поднялся с этим прокси. Метка infra честная, и это ровно #2686: диагноз приходит от типа исключения в месте порождения, а не из разбора текста.

Почему именно полный обход. Не параметры — concurrency=1, задержка та же, что у городских; гипотеза «душит сайдкар параллелизмом» опровергнута параметром. Причина в другом: полный обход — единственная задача Авито, реально проходящая через конструктор скрапера. Городские подменяют фетчер уже готовым. А конструктор до PR #2637 (02.08) строил фетчер без провайдера прокси — аренды нет, в запросе к сайдкару нет адреса, сайдкар идёт на мёртвый статичный прокси. Четыре из шести банов — строго до этой правки.

210 секунд — не таймаут, а лестница

Моё «три подряд ровно по 210 секунд похоже на настроенный таймаут» тоже неверно. Это 4 × (6 запросов × ~7.1 с + паузы), где четвёрка — предел подряд идущих блокировок. Городские перевыбрасывают на первом якоре, отсюда ровно 210 против 50. Посекундная воспроизводимость — признак детерминированной лестницы, а не настройки.

Починено попутно, и это настоящий дефект

NoProxyAvailableError наследуется от RuntimeError и попадал в общий перехват, ведущий к «отказу» — а тот не пишет чекпоинт. То есть при исчерпании пула полный обход терял пройденные корзины.

Это связано с тем, что я потерял 09.08: там чекпоинт сохранился (был cancelled), но при отказе пула не сохранился бы вовсе.

PR #2834 смержен, тест красный на старом коде (assert 'unknown' == 'infra').

Владельцу, числом

Три узла под Авито; девять неудачных запросов опустошают пул под источник, а лестница одного полного обхода делает двадцать четыре. То есть полный обход способен опустошить пул в одиночку. Ротация ждёт токен ASOCKS (#2638).

Что остаётся непроверенным, с датой

Что обход завершается на исправленном тракте — не проверено. Точки: 16.08 13:37 и 17.08 14:29. До них вопрос «нужны ли два обхода» остаётся преждевременным.

## Моя статистика была неверна: окно легло поперёк границы двух эр Вчера я написал: «семь из семи против трёх из семнадцати, вероятность пять миллионных — разница настоящая». **Это ошибка сравнения**, и вот в чём. Проверил на проде: ``` последний infra-бан ЛЮБОГО источника → 03.08 13:37 после 04.08 инфраструктурных банов → 0 ``` Баны Авито по эрам за 21 сутки: | эра | infra | platform | unknown | |---|---:|---:|---:| | **до 04.08** | **42** | 2 | 0 | | **после 04.08** | **0** | 7 | 1 | 04.08 смержены #2634/#2640 — починка сайдкара. Инфраструктурные баны прекратились у **всех** источников разом. Моё двухнедельное окно захватило обе эры, и числитель с знаменателем оказались из разных: шесть из семи прогонов полного обхода — **до** починки, одиннадцать из семнадцати городских — **после**. Я сравнивал сломанное прошлое одного с починенным настоящим другого. Честное сравнение внутри одной эры: | источник | прогонов после 04.08 | забанено | |---|---:|---:| | `avito_city_sweep` | 11 | 1 | | `avito_full_load` | **1** | 1 | Один прогон против одиннадцати. **Выводить из этого нечего** — ни «сломан особым образом», ни «не сломан». Это ровно та ошибка, от которой у нас есть правило: размечать помехи **до** окна наблюдения, а не после. Я окно выбрал круглым числом (две недели), а не по границе изменений. ## Что оказалось причиной шести падений Поле `error` (не `error_text`, он пуст) у **всех шести** несёт один текст: ``` avito full load aborted: avito SERP browser-sidecar error (page=1): browser unavailable (proxy may be down) ``` Это 503 нашего сайдкара — браузер не поднялся с этим прокси. **Метка `infra` честная**, и это ровно #2686: диагноз приходит от типа исключения в месте порождения, а не из разбора текста. **Почему именно полный обход.** Не параметры — `concurrency=1`, задержка та же, что у городских; гипотеза «душит сайдкар параллелизмом» опровергнута параметром. Причина в другом: полный обход — единственная задача Авито, реально проходящая через конструктор скрапера. Городские подменяют фетчер уже готовым. А конструктор **до PR #2637 (02.08)** строил фетчер **без провайдера прокси** — аренды нет, в запросе к сайдкару нет адреса, сайдкар идёт на мёртвый статичный прокси. Четыре из шести банов — строго до этой правки. ## 210 секунд — не таймаут, а лестница Моё «три подряд ровно по 210 секунд похоже на настроенный таймаут» тоже неверно. Это `4 × (6 запросов × ~7.1 с + паузы)`, где четвёрка — предел подряд идущих блокировок. Городские перевыбрасывают на первом якоре, отсюда ровно 210 против 50. Посекундная воспроизводимость — признак **детерминированной лестницы**, а не настройки. ## Починено попутно, и это настоящий дефект `NoProxyAvailableError` наследуется от `RuntimeError` и попадал в общий перехват, ведущий к «отказу» — а тот **не пишет чекпоинт**. То есть при исчерпании пула полный обход терял пройденные корзины. Это связано с тем, что я потерял 09.08: там чекпоинт сохранился (был `cancelled`), но при отказе пула не сохранился бы вовсе. PR #2834 смержен, тест красный на старом коде (`assert 'unknown' == 'infra'`). ## Владельцу, числом Три узла под Авито; девять неудачных запросов опустошают пул под источник, а лестница **одного** полного обхода делает **двадцать четыре**. То есть полный обход способен опустошить пул в одиночку. Ротация ждёт токен ASOCKS (#2638). ## Что остаётся непроверенным, с датой Что обход **завершается** на исправленном тракте — не проверено. Точки: **16.08 13:37** и **17.08 14:29**. До них вопрос «нужны ли два обхода» остаётся преждевременным.

bot-backend referenced this issue from a commit

2026-08-12 20:55:07 +00:00

fix(tradein/domclick): распознанный QRATOR-блок свипа — ban_kind='platform', не 'unknown' (#2687) (#2832)