193 commits

Author	SHA1	Message	Date
bot-backend	83946e5d4f	Merge pull request 'fix(scraper-kit): дрейн-метка interrupted=1 у domclick sweep и трёх full-load — резюм после SIGTERM для всех функций с чекпоинтом' (#3363) from fix/3355-drain-mark-fullloads into main	2026-09-05 19:28:25 +00:00
bot-backend	12945d7b2f	fix(scraper): дрейн domclick сохраняет чекпоинт, дрейн cian-detail помечается ... Ревью PR #3363: 1. domclick city sweep: комментарий обещал, что унаследованный при claim чекпоинт переживёт дрейн «jsonb-мержем» — мержа нет. domclick пишет counters через app-level scrape_runs (update_heartbeat/mark_done делают `counters = CAST(:counters AS jsonb)`, полная перезапись), а scheduler при claim done_buckets не наследует. Дрейн закрывал прогон с ПУСТЫМ чекпоинтом, резюм пересобирал все шесть корзин. Чтение чекпоинта поднято выше ранних выходов, дрейн-payload несёт `done_buckets` явно — как уже делает ban-ветка (except NoProxyAvailableError) той же функции. 2. cian full-load, detail-фаза: второй ранний выход по shutdown_requested() делал `break` и уходил в обычный mark_done — SERP целый, обогащение обрезано, а прогон выглядел полным. Теперь тот же sentinel RuntimeError("shutdown"), что и в _on_bucket: interrupted=1 + done_buckets. 3. yandex/avito full-load проверены: по одному shutdown-сайту в _on_bucket, detail-фазы нет вовсе — аналогичного дефекта нет. Тесты: чекпоинт дрейна domclick сверяется ПО ЗНАЧЕНИЮ в обеих записях (heartbeat + финализатор); дрейн cian в detail-фазе даёт interrupted=1.	2026-09-06 00:21:55 +05:00
bot-backend	6ced16618c	Merge pull request 'fix(tradein/yandex): недорендеренная карточка — отказ, не успех: структурный маркер encryptedPhones + порог размера, карточка остаётся в очереди' (#3364) from fix/3191-yandex-detail-completeness into main	2026-09-05 19:21:06 +00:00
bot-backend	29c0ae006d	Merge pull request 'fix(scraper-kit): containment до пробы у cian и yandex — резюм full-load не пере-пробивает готовые полосы' (#3362) from fix/3359-containment-cian-yandex into main	2026-09-05 19:19:31 +00:00
bot-backend	78e3da6bc3	fix(tradein): маркер полноты — encryptedPhones ИЛИ redirectPhones (#3191) ... Ревью #3364. Требуя именно encryptedPhones, отбраковывали бы вечно необмеренный класс карточек «без телефона / только чат»: в очередь они возвращаются, а ключ не появится. redirectPhones измерен тем же замером #3192 и присутствует в обеих ветках (с куками и без). Текст ABORT: consecutive_none смешанный (фетч-ошибка + parse-None + недогруз) — «N подряд без обогащения», а не «недогруженных».	2026-09-06 00:14:43 +05:00
bot-backend	4184f751bb	fix(yandex): degraded-бакет не зачитывается как пройденный ... Ревью #3362: в _degraded (probe провалился → пагинация до пустоты, обрезаемая max_pages_per_bucket) yandex звал on_bucket БЕЗ признака полноты, и ключ падал в done-леджер наравне с честно добранным листом. До containment-гейта это был точечный skip одного ключа; теперь ключ покрывает ИНТЕРВАЛ и сливается со смежными — недобранная после отказа полоса больше никогда не переобходится. Тот же путь, что у cian: третий позиционный аргумент complete, в чекпоинт пишет только _mark_bucket(..., True); partial_buckets вынесен в счётчики прогона (виден в heartbeat), лоты и cancel/shutdown-проверки не трогаем. Плюс комментарий смежности в bisection.py приводил полуоткрытый пример, споря с «hi ВКЛЮЧИТЕЛЬНА» в том же докстринге.	2026-09-06 00:13:11 +05:00
bot-backend	3a0b94e052	fix(scheduler): мерить свежесть источника данными, а не статусом прогона ... `_STALE_SOURCES_SQL` считала свежесть возрастом последнего прогона со статусом 'done'. Прогон с блоком честно финализируется как 'banned' (#2657) и при этом вставляет строки: у domclick_city_sweep 886 строк 25.08 и 128 строк 23.08 — оба 'banned'. Источник, регулярно ловящий блок и столь же регулярно приносящий данные, числился мёртвым навсегда, отсюда ложный P1 #3118 «домклик не собирается с 5 августа». Запрос отдаёт завершённые прогоны, решение «прогон дал данные» принимает `run_brought_data` ТЕМ ЖЕ результатным словарём, которым уже судит сторож нулевого результата (runs._RESULT_COUNTER_KEYS, #2703) — одна мера на оба механизма. Не 'lots_inserted': это новизна, а не наличие данных (здоровый дедуплицированный sweep вставляет ноль). Результат не измерен (28 источников без результатного ключа) → судим прежней мерой, статусом: «не измерено» ≠ «ноль». never_ok считается той же мерой, иначе соврал бы в другую сторону. Closes #3172	2026-09-06 00:02:21 +05:00
bot-backend	f6cf948358	fix(scraper): пометить SIGTERM-дрейн interrupted=1 у full-load'ов и domclick-свипа ... После #3330/#3346 резюм берёт 'done' только с counters.interrupted=1, но четыре функции с живым чекпоинтом done_buckets финализировали дрейн чистым 'done': cian/yandex/avito full-load (ветка RuntimeError("shutdown")) и domclick city sweep (дрейн до SERP). Оборванный обход был неотличим от полного, а собранные бакеты никто не подхватывал — у avito это ещё и бан-бюджет (#3315). done_buckets в domclick-payload не добавляем: чекпоинт унаследован при claim (#3074), jsonb-мерж его сохраняет. Closes #3355	2026-09-05 23:59:22 +05:00
bot-backend	4b5f8fb54c	fix(tradein): недогруженная карточка Яндекса — отказ, а не успех (#3191) ... Страница на 1,8 МБ без блока контактов приходит с HTTP 200 и валидным HTML: window.INITIAL_STATE на месте, parse отрабатывает — и частичная карточка уезжала в БД с detail_enriched_at, выбывая из очереди навсегда. Единственная проверка размера (newbuilding.py, len(html) < 500) отвечала на вопрос «пришло ли хоть что-то»: 1,8 МБ проходит её в 3600 раз. Признак полноты структурный + размерный, любой из двух даёт отказ: encryptedPhones (65 вхождений у полных карточек, 0 у недогруза; отдаётся и анонимной сессии — см. yandex_session.py) и settings.yandex_detail_min_html_bytes (1 МБ). Наблюдавшийся недогруз ловит именно структурный: 1,8 МБ порог проходит. В backfill проверка стоит ДО parse: исход incomplete ⊆ failed, save не вызывается, значит detail_enriched_at не проставляется и следующий снапшот (detail_enriched_at IS NULL) возьмёт объявление снова. Серия недогрузов двигает consecutive_none — тот же брейкер, что у parse→None, поэтому вечно недогружаемая карточка обрывает прогон, а не молотится (per-listing счётчика попыток в схеме нет). Фейковые ответы в тестах-соседях (#3196/#3338) теперь при HTTP 200 выглядят полной страницей — иначе они молча стали бы кейсами про полноту.	2026-09-05 23:59:15 +05:00
bot-backend	35c7ea8492	fix(cian,yandex): skip fully-covered price ranges before probing on resume ... Гейт should_skip живёт в общем движке (walk_price_range, #3315), но предикат из done-леджера строил и передавал только avito. У cian и yandex та же бисекция и тот же чекпоинт — на резюме дерево деления спускалось ВНУТРЬ зачтённых полос живыми probe-запросами: ключи чекпоинта суть границы ДИНАМИЧЕСКОЙ бисекции, при сдвиге рынка новый лист старому не равен даже внутри собранной территории, поэтому сравнение строк ничего не ловит. Формат ключей у провайдеров разный, и ключи не трогаем (иначе протухнут живые чекпоинты): cian пишет room_label:lo:hi / :open — как avito, парсер подходит без изменений; yandex пишет _combo_label «rooms:lo-hi» с «None» вместо открытого потолка, поэтому в done_range_skipper параметризованы range_sep и open_token (дефолты = прежнее поведение avito/cian). Один леджер на два режима: у yandex incremental-ключи несут префикс сегмента (secondary/2:…) и отсев по label их не пропускает, а смешение режимов блокирует _pick_resume (params IS NOT DISTINCT FROM); у cian incremental-режима нет вовсе. Записано в докстринге предиката. Тесты по значению на обоих провайдерах: счётчик стоит на горлышке фетча (_fetch_page_html / _fetch_page_json), резюм готовой комнатности = 0 запросов, частично покрытая полоса по-прежнему пробивается. Closes #3359	2026-09-05 23:56:46 +05:00
bot-backend	63dbc209b2	Merge pull request 'fix(scraper-kit): бан площадки не гасит здоровье узла для всех источников — report_ban по паре узел×источник вместо mark_health(ok=False)' (#3357) from fix/3288-avito-ban-per-source into main	2026-09-05 18:36:29 +00:00
bot-backend	e48b4a47d7	Merge pull request 'fix(tradein/domclick): дом-поля карточки → houses, backfill total_units/material_* из raw_payload (миграция 284)' (#3356) from fix/3253-domclick-house-fields into main	2026-09-05 18:26:18 +00:00
bot-backend	c57138f4c7	fix(tradein/proxy): бан площадки рапортует только фетчер — ротация больше не банит свежий узел ... Дедуп report_ban по _banned_lease_id не достигал цели при ротации. Узел 13 ловит бан-страницу → фетчер репортит бан 13 и по fail-streak меняет lease на 14 → провайдерский report_ban в providers/avito/detail.py видит уже сброшенный _banned_lease_id и банит СВЕЖИЙ узел 14, который к площадке не ходил. При трёх узлах в пуле одна бан-страница выбивала две трети выдачи на 6 часов с эскалацией ban_count. Убран провайдерский report_ban на ветках SidecarBanPageError в avito/detail.py и domclick/detail.py: фетчер репортит сам, раньше и по правильному lease. Детекты не от сайдкара (firewall / 0 карточек в serp.py, QRATOR-маркеры parse_detail_html) фетчеру не видны — там report_ban остаётся. Плюс два смежных: fetch()-ретрай ловил httpx.HTTPError, подклассом которого является SidecarBanPageError, — каждая бан-страница стоила 2 POST'а и +2 к fail-streak (ротация вдвое раньше задуманного); и NoProxyAvailableError из ротационного _acquire_lease внутри _report_platform_ban вылетала ВМЕСТО SidecarBanPageError, подменяя диагноз platform на infra — теперь ротация там best-effort. Тесты: рабочий пул теперь РОТИРУЮЩИЙ (13→14) — на неподвижном пуле дефект физически не проявляется. Два теста, пинившие прежний контракт (провайдер репортит), инвертированы: у них MagicMock-фетчер, который настоящего рапорта не делает. Refs #3288	2026-09-05 23:25:19 +05:00
bot-backend	0e4a227a5a	Merge pull request 'fix(scraper-kit): пропуск по куке двигает next_run_at на interval_minutes, а не на случайный час завтра' (#3351) from fix/3312-defer-interval-minutes into main	2026-09-05 18:22:41 +00:00
bot-backend	d518efbed1	fix(tradein/domclick): дом-поля едут в словаре ДОМ.РФ, а не сырьём Домклика ... houses.material_walls уже заполнена словарём ДОМ.РФ (капремонт КР1.2, #2013): кирпич 2662, железобетонная панель 2107, иное 1850, монолит 754. Ветка писала туда сырую фразу карточки (Монолитный 2656, Кирпичный 2241, Панельный 1671, Монолитно-кирпичный 773) — колонка стала бы двухсловарной, и `WHERE material_walls = 'монолит'` перестал бы видеть весь Домклик. Ровно та болезнь, которую sale_type уже пережил в #2674. canon_wall_type / canon_floor_type стоят на границе записи в houses (как canon_sale_type — на границе записи в listings): Кирпичный→кирпич, Панельный→железобетонная панель, Монолитный/Монолитно-кирпичный→монолит, Блочный/Деревянный→иное, Железобетонный→Железобетонные (форма, уже лежащая в колонке). Незнакомое → None + warning раз на процесс: сырьё в колонку не попадает никогда, а новое значение словаря видно в логах. В raw_payload сырая фраза площадки остаётся как была. Миграция 284 получила тот же CASE lower(...) — иначе backfill залил бы задним числом ровно то, что код перестал писать. CASE без ELSE: незнакомое → NULL.	2026-09-05 23:17:50 +05:00
bot-backend	25d3db2ae7	Merge pull request 'fix(scraper-kit): резюм exhaustive не пере-пробивает готовые полосы — containment по done-леджеру до пробы, 17 911 запросов → 0' (#3358) from fix/3315-exhaustive-containment-skip into main	2026-09-05 18:17:01 +00:00
bot-backend	7322615868	Merge branch 'main' into fix/3312-defer-interval-minutes	2026-09-05 18:15:47 +00:00
bot-backend	c048e8f2c9	fix(avito): skip fully-covered price ranges before probing on resume ... Резюм exhaustive-обхода пере-пробивал уже зачтённую территорию: skip проверялся в листе, ПОСЛЕ probe, поэтому дерево бисекции спускалось в поддиапазоны done-корзин живыми запросами (прогон 5718: 21 минута внутри room_studii:4000000:4999999, ноль новых корзин). На пуле из 1-2 нод это сжигает весь бан-бюджет до первой НОВОЙ работы. Ключи чекпоинта — границы ДИНАМИЧЕСКОЙ бисекции: при сдвиге рынка новый лист ключом не равен старому даже внутри покрытого диапазона, поэтому сравнение строк бесполезно. done_range_skipper парсит ключи room:lo:hi (hi=open → бесконечность) в отрезки, сливает пересекающиеся и смежные и отдаёт предикат покрытия; walk_price_range проверяет его на входе в узел, ДО probe, и обрезает готовые поддеревья без единого запроса. Closes #3315	2026-09-05 23:06:26 +05:00
bot-backend	3b8545f609	fix(tradein/proxy): бан площадки снимает узел адресно, а не гасит его здоровье для всех источников ... Сайдкар на бан-странице Авито отвечает HTTP 500 с ban_page-маркером, клиент поднимает SidecarBanPageError — но она подкласс httpx.HTTPStatusError, и общий except Exception в _post_fetch звал mark_health(ok=False). Это ГЛОБАЛЬНОЕ решение по узлу: три бан-страницы Авито выбивали его из выдачи и Яндексу, и Циану, и Домклику (прод-замер 31.08-01.09: узлы 9/13/14 на потолке MAX_CONSECUTIVE_FAILS при banned_for_source=0, живая проба тех же узлов проходила). Теперь бан-страница ловится отдельной веткой ДО общего except и уходит в mark_banned(source=...) — приговор паре «узел×источник», которую фильтрует acquire(source). Здоровье узла не трогаем; транспортный сбой (таймаут, плоская 500) как и раньше идёт в mark_health(ok=False). report_ban дедуплицирован по lease: одно событие доезжало до него трижды (POST, ретрай fetch(), провайдер), а каждый вызов растит ban_count и кратно удлиняет отдых пары. Refs #3288	2026-09-05 23:03:33 +05:00
bot-backend	2532bcbe27	fix(tradein/domclick): дом-поля карточки → houses, backfill total_units (#3253) ... Парсер карточки Домклика читал houseInfo.info и складывал блок дома целиком в listings.raw_payload; в houses не переносил ничего. Замер 29.08: total_units = 0 у ВСЕХ источников, хотя quarters_count уже лежал в собранных payload'ах. save_detail_enrichment получает второй оператор — тот же fill-only паттерн, что у avito (#3036), связь через listings.house_id_fk: quarters_count → total_units, wall_type → material_walls, floor_type → material_floors. COALESCE в SET и в WHERE-гейте: непустое значение дома не затирается (у houses есть конкурирующие писатели — ДОМ.РФ капремонт, Houses Catalog). Серия дома, энергоэффективность и число подъездов остаются в raw_payload — колонок под них нет, схему не расширяем. Миграция 284 переливает то же самое задним числом из уже собранных payload'ов, только в пустые колонки, идемпотентно, под lock_timeout.	2026-09-05 22:57:00 +05:00
bot-backend	63e2210abd	fix(scheduler): defer уважает interval_minutes источника ... _defer_next_run_at (путь пропуска pre_claim — например протухшие куки Циана) читал только interval_days, поэтому cian_detail_backfill с каденцией 360 мин после пропуска получал случайный час завтрашних суток: от ~1 до ~47 часов вместо шести. Ручное обновление кук не давало эффекта ещё сутки. Разбор interval_minutes вынесен в _interval_minutes и переиспользован post_claim-хуком reschedule_after_minutes — два входа в одну каденцию. Нижний порог _MIN_DEFER_MINUTES = 3 тика планировщика сохраняет #1522: defer обязан пережить несколько get_due_schedules, иначе pre-check снова гоняется каждую минуту. Refs #3312, #1522	2026-09-05 22:50:58 +05:00
bot-backend	ac11156f7d	fix(scraper-kit): метка дрейна interrupted=1 во всех city-свипах (#3333) ... После #3319 резюм подхватывает 'done'-прогоны только с counters.interrupted (_drained_done в scheduler._resume_decision), но ставил метку ровно один avito_city_sweep. У yandex, cian и newbuilding SIGTERM-drain финализировался чистым 'done' с частичными счётчиками: оборванный деплоем обход неотличим от полного и из резюма выпадал, хотя чекпоинт done_buckets есть у всех трёх (combo-метки / имена якорей / номера страниц). done_buckets в дрейн-payload не добавляю: heartbeat мержит jsonb, уже записанные единицы обхода переживают финализатор, а пустой список у multi-anchor yandex затёр бы унаследованный при claim чекпоинт.	2026-09-05 22:44:46 +05:00
bot-backend	41f21c4969	docs(scraper-kit): обоснование #3319 — что именно теряло чекпоинт ... Ревью опровергло формулировку «точку терял каждый финализатор»: все четыре писателя в runs.py мержат jsonb (`counters || :counters`), записанный ключ переживал mark_done/mark_banned/mark_failed. Правка закрывает выходы РАНЬШЕ первого end-of-anchor heartbeat (cancel/дрейн на первом якоре, ранний done #1950 на якоре №1) — комментарий и докстринг переписаны на это. Замер «0 из 67 за 60 дней» назван тем, чем он является: запись появилась 26.08.2026 (#3074) при такте avito 7 суток, выборка почти вся из эры без механизма. Плюс тест на прогон без ключей (эра до #3074) — метка дрейна не меняет вердикт «нечего подхватывать».	2026-09-02 14:53:02 +05:00
bot-backend	0ed934ea09	fix(scraper-kit): чекпоинт avito_city_sweep доживает до финализатора (#3319) ... 0 из 67 прогонов за 60 дней имели done_buckets в counters: точку писала одна строка внутри цикла якорей, а каждый выход (mark_done — включая ранний #1950 «SERP собран, detail заблокирован», — mark_banned, mark_failed) отдавал голый counters.to_dict(). Точка держалась только на jsonb-мерже в runs.py, то есть на свойстве чужого модуля, которого этот файл не проверяет. - payload любого выхода собирается одной функцией _ckpt() — done_buckets несут все 14 записей, а не одна; - якорь, умерший по таймауту, больше не считается пройденным (тот же инвариант, что у generic-except): SERP мог успеть, detail нет, и резюм пропускал такой якорь навсегда при штатно завершившемся прогоне; - SIGTERM-дрейн помечается counters.interrupted=1 и участвует в резюме. Статус остаётся 'done' — ни один читатель статуса не меняется; метка та же, что у rosreestr_dkp-дрейна. 'done' в _RESUME_STATUSES НЕ добавлен: чистый полный обход резюмить нечего. Дрейн перед IMV-фазой помечен отдельно (imv_phase_drained) — якоря там пройдены все, подхват собрал бы ноль.	2026-09-02 14:44:38 +05:00
bot-backend	dab2b43efc	imv: HTTP 429 больше не приговаривает дом навечно ... Алерты 01.09 (house_imv: RuntimeError('HTTP 429') / ('HTTP 400')) вскрыли дыру в классификаторе: _raise_for_status_categorized разбирает 401/403 и 5xx, а ВЕСЬ остальной 4xx проваливается в resp.raise_for_status() и приезжает в house_imv_backfill голым RuntimeError. Бэкфилл типизирует только IMV*-исключения — дом получает ТЕРМИНАЛЬНЫЙ imv_status='error' и выпадает из повторных пакетов навсегда. 429 — канонический ВРЕМЕННЫЙ отказ (rate limit), и механика повтора для таких существует (transient_error + retry-lane + лимит попыток #2674). Замер на проде: 19 домов заперты в error с причиной «HTTP 429» — ретраебельный отказ стал вечным приговором. 429 и 408 теперь IMVTransientError. 400 НАМЕРЕННО оставлен терминальным: тело безликое {"code":400,"message":"Bad Request"}, оснований считать его временным нет, а ретраебельный 400 значил бы вечно долбить дома с реально кривыми параметрами. Тест держит границу С ОБЕИХ СТОРОН — и «429 transient», и «400 НЕ transient». Фальсификация: снятие ветки 408/429 даёт 2 failed по значению (IMVTransientError не поднят), не ImportError. 9 passed, ruff чисто. Ремонт уже запертых строк — отдельным шагом после мержа: UPDATE 19 домов error→transient_error (починка разбора не чинит строки сама).	2026-09-01 21:21:53 +05:00
lekss361	72cb410b05	fix(tradein/avito): бан-страница площадки уезжала в транспортные сбои и не банила узел (#3283) (#3304) ... Co-authored-by: lekss361 <lekss361@gendsgn.local> Co-committed-by: lekss361 <lekss361@gendsgn.local>	2026-08-31 14:53:17 +00:00
lekss361	9219ab6507	feat(tradein/avito): ротация exit-IP по счётчику попыток в доборе карточек (#3302)	2026-08-31 12:09:03 +00:00
bot-backend	5c10aee4c2	fix(tradein/avito): browser-путь добора не смотрел на HTTP-статус — отказ площадки уходил в ошибку парсинга (#3297) ... Замер прода 31.08.2026 (24 попытки через 3 узла) поймал три отказа, которые доезжали до parse_detail_html и падали ValueError("Cannot extract item_id"): страница 8172 байта, статус 439, title «Доска объявлений от частных лиц и компаний на Авито». Отказ ПЛОЩАДКИ записывался generic-ошибкой разбора, узел не ротировался и не банился, брейкер по доле его не видел. Две независимые дыры, обе в browser-ветке fetch_detail: 1. last_response_status не читался вовсе. Curl-ветка того же файла статус проверяет (`if sc in (403, 439) or is_firewall`), browser-ветка смотрела только на HTML. Прод ходит именно browser-путём. 2. Маркер витрины-заглушки протух: искали «объявления на сайте авито», а фактический title — «доска объявлений от частных лиц и компаний на авито», подстрока в нём не встречается. Правка: - новые константы _AVITO_DETAIL_BROWSER_BLOCK_STATUSES = {403, 439} и _AVITO_DETAIL_BROWSER_RATELIMIT_STATUS = 429, источник каждого статуса назван комментарием; - проверка стоит ПОСЛЕ _is_detail_not_found (404 остаётся AvitoListingGoneError) и ДО parse_detail_html; - статус None (сайдкар старой версии, goto без статуса) отказом НЕ считается — поведение прежнее, фолбэк на html-эвристики; - 429 разведён с блокирующими статусами и поднимает AvitoRateLimitedError. Разница не косметическая: на AvitoBlockedError оркестратор один раз за прогон зовёт request_context_reset (#3251) и выбрасывает пройденный QRATOR-PoW. При rate-limit контекст цел, сбрасывать его — значит проходить проверку заново с того же IP. Зеркалит curl-ветку, где 429 тоже не блок; - старый title-маркер не удалён, а дополнен снятым вживую: площадка может отдавать обе формы. Тесты (9): каждый статус по отдельности, None-статус не ломает разбор и не подавляет html-эвристики, 404 побеждает блокирующий статус (порядок проверок), оба title-маркера опознаются, 429 не является AvitoBlockedError. Фальсификация: без правки detail.py 5 из 9 новых тестов падают. Прогон: 397 passed, 1 skipped (-k "avito or cadence or scheduler"), ruff чист. Замер намеренно жёстче прода (без прогрева сессии и органического перехода из выдачи), поэтому доля таких отказов в проде из него НЕ следует — её покажет счётчик после правки.	2026-08-31 14:16:47 +03:00
bot-backend	657fdbd1ba	Merge remote-tracking branch 'forgejo/main' into fix/3267-block-marker-in-listing-text	2026-08-30 12:08:46 +03:00
lekss361	169121cea8	Merge pull request 'fix(tradein/avito): браузерный путь ходил на каждую карточку холодным (#3251)' (#3267) from fix/3180-avito-warm-context into main	2026-08-30 08:55:33 +00:00
bot-backend	aec05280fa	fix(tradein/domclick): «система защиты от протечек» в объявлении читалась как блок QRATOR ... _extract_json искал маркеры блока подстрокой по ВСЕМУ телу ответа — до разбора JSON, то есть и по пользовательским описаниям объявлений. Прод 30.08, прогон 5363: продавец написал в описании квартиры «🔹 Система защиты от протечек». Подстрока совпала с маркером «система защиты», ответ на 107 183 байта с двадцатью валидными офферами был объявлен блок- страницей, свип оборвал все комнатные корзины и забанил живой узел пула на 6 часов. Совпасть так же могут «captcha» и «qrator» — в тексте объявления, в имени агентства, в ссылке. Порядок перевёрнут: сначала разбор JSON, маркеры — только если разбор не удался. Разобранный JSON нужной формы блок-страницей быть не может, QRATOR отдаёт HTML, так что валидный разбор сам по себе доказывает отсутствие блока. Тот же порядок давно применён в detail.py — там маркеры смотрят только когда __SSR_STATE__ не найден; свип был единственным местом с обратной логикой. Мусор без маркеров теперь ValueError, а не блок: за неразобранный ответ неизвестной природы узел банить нельзя. Тест проверен мутацией: со старым порядком 8 проверок из 11 краснеют, включая дословный фрагмент описания из прогона 5363.	2026-08-30 11:49:47 +03:00
bot-backend	58e18e6fec	fix(tradein/avito): браузерный путь ходил на каждую карточку холодным (#3251) ... Пройденный QRATOR proof-of-work выбрасывался после каждой карточки: `reuse_context` во всём репозитории передавал ЕДИНСТВЕННЫЙ вызов — domclick_detail_backfill.py:346. Значит каждый /fetch Авито шёл через sidecar'овский browser.new_page(), то есть новый изолированный context с пустой банкой кук. В логе прод-сайдкара это видно прямо: «PoW-челлендж снят за ~1000мс» печатается на КАЖДОЙ успешной карточке — челлендж решается заново каждый раз, а не один раз на прогон. Эффект той же правки у Домклика измерен и записан в domclick_detail_backfill.py:331 — 26 последовательных фетчей сайдкара дали 100% блоков, те же карточки в тёплом контексте 5/5 за ~2с. Второй холод — сам заход: providers/avito/detail.py звал fetch(full_url) голым, без origin и без Referer, тогда как Домклик (#3247) идёт fetch(card_url, origin=SERP, referer=origin). Существующий для Авито прогрев (warm_up_session) живёт только в curl-пути и с 22.08 в проде мёртв — AVITO_DETAIL_BACKFILL_USE_CURL выставлен в false. Что сделано: - avito_detail_backfill: reuse_context=True + request_context_reset() РОВНО один раз за прогон и только на AvitoBlockedError. Не на AvitoSidecarUnavailableError (подтип AvitoRateLimitedError — отказ нашего тракта, не бан площадки) и не на AvitoListingGoneError. Зеркалит #3212: сброс на каждый блок сам себя поддерживает — пропуск живёт в context'е, сброс его выбрасывает, повторная проверка с того же IP снова блокируется, одна осечка даёт каскад. - fetch_detail: необязательные origin/browser_referer (имя referer уже занято под Referer curl-пути, это разные фетчеры и разные поля). Дефолт None → payload и поведение city_sweep/pipeline/admin не меняются. - _serp_origin_for: городская SERP из URL карточки, хост берётся из самого url. Попутно — дефект якорной вкладки сайдкара, найденный при переносе. _ensure_anchor_page отдавала True на ЛЮБУЮ живую вкладку, не сверяя её с запрошенным origin. А origin у обоих caller'ов выводится ИЗ URL карточки и меняется вместе с городом (Авито — сегмент пути, Домклик — поддомен). После первой же карточки другого города Referer называл выдачу, которую этот контекст никогда не открывал: ни куки её, ни тайминга, площадка видит заявленный переход без единого следа. Ровно то, что #3258 запретил делать фолбэкам якорного поиска. Добавлен _anchor_origins: origin сменился — вкладка переоткрывается. Чинит и Домклик тоже. Заход через поиск Яндекса (BROWSER_ANCHOR_VIA_SEARCH) для Авито НЕ включается — расширять этот список без отдельного замера запрещает комментарий у самой константы. Хранилище авторизованных сессий Авито (#3179/#3180) этой правкой не заменяется. База для сравнения снята ДО выката и записана в #3251: доля блоков от попыток 46.9% / 74.2% / 96.4% / 69.8% / 52.9% / 62.3% по суткам 25-30.08. Сравнивать после деплоя по доле блоков и обогащению за сутки, а НЕ по статусу прогона: ratio-критерий обрывает КАЖДЫЙ прогон, и статус banned про площадку ничего не говорит. Тесты: backend 5150 passed / 37 skipped, сайдкар 211 passed (было 206 + 5 новых на переезд якоря), ruff чист. Refs #3251, #3180, #3118, #3212, #3247, #3258	2026-08-30 11:47:15 +03:00
bot-backend	5baf07d6e6	fix(tradein/domclick): свип брал BFF навигацией браузера — теперь подзапросом (#3264) ... BFF-ручка Домклика не страница, а JSON-эндпоинт SPA. Сайдкар умел ровно одно — page.goto(url), — и навигацией браузера на API-хост мы делали то, чего настоящий клиент не делает никогда. Перехват сети на живой выдаче 30.08 это и показал: офферы приезжают в SSR-документе, а к BFF ходят XHR'ы за гео, районами и метро. Через мобильные узлы пула такая навигация упиралась в ChallengeTimeout: прогоны 5330 и 5351 — 9 из 9 и 6 из 6 запросов зависли на челлендже, 0 лотов. Карточки через те же узлы в те же минуты шли. Замер трёх режимов на одном узле, один и тот же ресурс: BFF navigate ChallengeTimeout, 55с BFF subresource HTTP 200, 52 байта, 6с BFF page_fetch ошибка Подзапрос проверен вширь: все шесть комнатных корзин HTTP 200, суммарно 6359 офферов против 6367, снятых напрямую с резидентного IP (расхождение — дрейф фонда за пару часов); список офферов отдаётся на всех четырёх узлах пула, по 20 штук, 120 КБ. Сайдкар получил fetch_mode: navigate (дефолт, прежнее поведение), subresource (context.request.get из прогретого контекста) и page_fetch (fetch из страницы). Третий оставлен, потому что теоретически он ближе всего к настоящему XHR, но в замере отказал — выбор сделан измерением, а не рассуждением. Прогрев origin обязателен: рукопожатие QRATOR попадает в куки контекста именно при заходе на страницу, поэтому свип теперь передаёт origin и referer, которых раньше не передавал вовсе. _decode_body распаковывает gzip по магическим байтам — карта офферов приезжает Content-Type: application/gzip, и без этого вызывающий получил бы бинарь в поле "html". Сама карта, к слову, подзапросом всё равно не берётся (279 байт — загрузчик QRATOR), но BFF полнее: 100% фонда против 62% у карты. fetch_mode кладётся в payload только когда он не дефолтный — сайдкар прежней версии не должен получать незнакомый ключ (тот же приём, что с referer в #3247). Тесты: сайдкар 212 passed (новый test_server_fetch_mode.py — 6 проверок), backend 316 passed (новый test_3264_sweep_subresource_mode.py — 5). Три тестовых дублёра _do_fetch/_post_fetch знали старую сигнатуру — обновлены.	2026-08-30 11:24:28 +03:00
bot-backend	44633b0df4	fix(tradein/domclick): свип ходил на QRATOR без кук и вис на PoW каждым запросом (#3264) ... serp.py не передавал куки сессии вообще — слова cookie в файле не было. Свип приходил к QRATOR с чистым браузером и был обязан решать proof-of-work с нуля на каждый запрос. Прод, прогон 5330 (30.08 03:49-03:55): 9 запросов к bff-search-web.domclick.ru, все 9 зависли на челлендже (перезагрузка 1/2, 2/2, отказ), status=failed, 0 лотов. Прокси при этом ротировался (узел 9 → 10) — узел тут ни при чём. Добор с тем же сайдкаром и тем же пулом в ту же ночь взял 37 карточек из 37 без единого блока. Разница ровно в куках. Чинить это стало возможно только сейчас: свип ходит не на ekaterinburg.domclick.ru, а на отдельный хост bff-search-web.domclick.ru, и до правки _cookie_domain (PR #3262) куки легли бы на .bff-search-web.domclick.ru, не совпав с сессией площадки. Теперь оба хоста схлопываются в общий .domclick.ru. Снимок приходит параметром снаружи, а не читается внутри kit: kit не импортирует app.* (strangler-инвариант #2133). Поэтому джоба domclick_city_sweep переопределена продуктовым Handler'ом — build_registry это прямо допускает («последнее слово за продуктом»), а БД читает только app-сторона. Отсутствие сессии не авария: load_session вернул None → свип идёт как раньше, без инъекции, факт логируется один раз. Цена решения — override повторяет вызов kit-джобы целиком и может тихо с ней разойтись. Добавлен тест, который зовёт оба джоба одинаково и сравнивает наборы kwargs, допуская расхождение ровно в cookies. Проверен мутацией: с искусственно добавленным в kit-версию аргументом краснеет, без него зелёный. Тесты: 245 passed, 1 skipped (domclick + parity).	2026-08-30 09:40:21 +03:00
bot-backend	ff0a15d443	feat(tradein/browser): ходить по Домклику как человек — с Referer и с перезагрузкой зависшего рукопожатия ... Добор карточек Домклика упирался в отказ на 11-й карточке: прогон 5298 дал attempted=13, enriched=10, blocked=3. Ручные прогоны в живом браузере брали 91 и 40 карточек без единого отказа. Разбор нашёл два отличия, и оба оказались нашими, а не площадки. 1. Referer не отправлялся НИКОГДА. playwright'овский goto() по умолчанию этот заголовок не шлёт, а параметр `referer`, который он принимает, мы не передавали. Площадка видела десяток появлений подряд прямо на URL карточки, без источника перехода — так не ходит ни один человек. Комментарии в коде при этом уверяли про «органическую навигацию с реальным Referer»; они врали, теперь исправлены. Сайдкар принимает `referer` в теле /fetch и ставит его ТОЛЬКО на целевую навигацию; на origin и якорную вкладку не ставит — туда приходят «сами». Добор Домклика передаёт страницу выдачи, чем переход и является по смыслу. 2. Зависшее рукопожатие не перезагружалось. _wait_out_pow_challenge построен на допущении «страница перезагрузит себя сама после решения PoW»; ручная сессия 29.08 через узел 10 это опровергла — выдача осталась на 401, и пропуск qrator_jsid2 выдался только после ДВУХ перезагрузок, сделанных руками: 102.7с GET → 401, 115.1с GET → 401, 118.4с GET → 200, следом кука-пропуск, и карточка за 6 секунд. Пока мы только опрашивали content(), такая страница жила до таймаута, а бэкфилл засчитывал это в блоки. Теперь после BROWSER_CHALLENGE_RELOAD_AFTER_MS (8с) сайдкар перезагружает сам, не больше BROWSER_CHALLENGE_MAX_RELOADS (2) раз за фетч. Оба пути безопасны на откат: без поля `referer` в теле поведение прежнее, BROWSER_CHALLENGE_RELOAD_AFTER_MS=0 возвращает прежний опрос без навигаций, упавшая перезагрузка не роняет фетч — опрос продолжается в том же бюджете. Тесты: 191 passed в сайдкаре (было 182) — 4 на Referer, 5 на перезагрузку, в том числе «страница ожила сама → лишней навигации нет» и «висит вечно → не больше лимита». Точечные backend-тесты домклика и scraper_kit — 144 passed.	2026-08-29 22:53:11 +03:00
lekss361	3d51c08e44	Merge pull request 'fix(tradein/domclick): подтверждённый отказ площадки уехал в ветку «сбой транспорта» и перестал банить узел' (#3241) from fix/3239-sidecar-ban-page-reaches-ban-path into main	2026-08-29 16:18:50 +00:00
bot-backend	c5784e85bc	fix(tradein/domclick): подтверждённый отказ площадки уехал в ветку «сбой транспорта» и перестал банить узел ... #3237 научил сайдкар опознавать статический отказ Домклика самостоятельно — это правильно и работает, но вместе с распознаванием ban-сигнал переехал не туда. Отказ стал приезжать обычной 500-кой: browser_fetcher обнуляет на ней last_response_status, и в detail.py срабатывает ветка except Exception, которая по построению НЕ зовёт report_ban («не подтверждённый маркер-бан, а сбой транспорта», #2600 п.4). Итог на проде (прогон 5287): ban_kinds сменился с platform на unknown, и при шести «статический отказ площадки» подряд в логах сайдкара в scrape_proxy_source_bans не появилось НИ ОДНОЙ записи. Это не косметика счётчиков — platform единственный диагноз, запускающий ротацию IP, поэтому мы продолжали бы долбиться в отказавший узел вместо перехода на свободный. Правка возвращает отказ на ban-путь, сохраняя разделение, ради которого #3237 и делался: - сайдкар кладёт в тело ошибки структурный признак ban_page и апстрим-статус. HTTP-код НЕ меняем: на 500 завязана classify_browser_probe; - SidecarBanPageError — подкласс httpx.HTTPStatusError, поэтому ловля у прочих поставщиков и retry-политика fetch() не замечают нового типа; - detail.py различает две ветки: подтверждённый отказ → report_ban + статус из исключения, транспортный сбой — как раньше. Статус несём отдельным полем, а не через last_response_status: на error-пути fetch() его обнуляет, а у Домклика отказ приходит с 401, без которого классификатор ставит unknown. Подстрокой в тексте исключения признак искать нельзя — _raise_for_sidecar_status обрезает тело до 300 символов, и формулировка отказа менялась дважды за месяц. Тесты держат обе ветки раздельно на всех трёх уровнях: сайдкар (признак есть у бан-страницы, отсутствует у транспортной ошибки), фетчер (тип и upstream_status, включая ловушку bool-как-int из #3196), detail.py (report_ban зовётся / не зовётся, статус доезжает). Closes #3239	2026-08-29 19:12:36 +03:00
bot-backend	3059f09e53	docs(tradein/domclick): два комментария описывали пул, которого нет с миграции 253 ... Оба места утверждали, что у Домклика один выделенный резидентный прокси и пула нет. Это перестало быть правдой ещё в #2800 (миграция 253 сняла резервацию узла), но текст остался — и именно на него опирался тикет #3189, поставленный под «калибровку» ограничения, которого не существует. Свип к тому же ходит через пул давно (serp.py:359), а бэкфилл подключён к нему в PR #3222. Заодно докстринг называл не тот ограничитель: свип кладёт не счётчик провалов lease, а break по первому DomClickBlockedError (#2854) — до ротации дело не доходит ни при каком счётчике, отсюда buckets_completed=0. Только комментарии, поведение не меняется. Миграция 175 уже применена, а _schema_migrations трекает по имени файла без checksum — правка текста её не перезапустит.	2026-08-29 18:58:51 +03:00
lekss361	195f9f3697	Merge pull request 'chore(tradein): две ручки ротации без читателей и врущий комментарий над ними' (#3232) from chore/3212-dead-rotation-knobs into main	2026-08-29 14:57:40 +00:00
bot-backend	1141035899	chore(tradein): две ручки ротации, которых не осталось читателей, и врущий комментарий над ними ... proxy_rotate_attempts / proxy_rotate_attempt_timeout_s тюнили ретраи changeip-GET. Сам changeip снят в #2616 шаг 2 (аккаунт mobileproxy закрыт, ссылки нет), и с тех пор ручки живут пламбингом: Settings -> property адаптера -> поле протокола ScraperConfig -> и всё. Ни одного потребителя, только четыре теста, которые заполняют их при сборке конфига. Комментарий над ними в contracts.py оправдывал их сохранение так: «оставлены как budget-верхняя-граница для app.tasks.avito_detail_backfill wait_for» — но wait_for там берёт СОСЕДНЕЕ поле, avito_proxy_rotate_settle_s (avito_detail_backfill.py:249). То есть комментарий приписывал этим двум полям работу третьего и тем самым прикрывал их мёртвость. Соседние ручки проверены и ОСТАВЛЕНЫ, они действительно читаются: * avito/cian/yandex_proxy_max_rotations — pipeline._max_rotations; * avito_proxy_rotate_settle_s — asyncio.wait_for в avito_detail_backfill. Заодно сжат комментарий в config.py: перечисление истории changeip заменено на то, что нужно знать сейчас — кто читает оставшиеся две ручки и где живая ротация (ASOCKS_API_TOKEN / proxy_rotation, #2611). ruff clean, 4974 passed / 37 skipped.	2026-08-29 17:07:04 +03:00
bot-backend	4902d1e29e	chore(tradein): четыре символа, на которые нет ни одной ссылки ... Найдено сверкой двух независимых источников: подсчёт упоминаний по всем python-файлам (включая тесты) дал имена, встречающиеся ровно один раз — в собственном объявлении; каждое затем подтверждено serena find_referencing_symbols (LSP, видит и косвенные ссылки) и проверено grep'ом по yml/sql/ts/md на случай ссылки строкой. Удалено: * _qr_code_data_url (trade_in_pdf) — QR как SVG data URL, не вызывался ниоткуда; вместе с ним ушёл осиротевший import segno. `io` ОСТАВЛЕН — io.BytesIO используется дальше по файлу (строка 774); * _local_name (gar_flats_loader) — снятие namespace с имени тега; * AvitoParseError — класс никто не поднимает и не ловит; * IMVCityMismatchError — то же. Что НЕ тронуто, хотя фильтр их показал: * ~200 обработчиков FastAPI и celery-задач — их поднимает декоратор, по имени их действительно никто не зовёт; * refresh_ddu_price_indicator — точка ручного обслуживания, задокументирована в комментарии к матвью (data/sql/152_mv_ddu_price_indicator.sql: «Refresh: ... (не в beat)»); * schemas/parcel.py::MarketPrice — половина контракта, фронт использует (frontend/src/types/site-finder.ts: market_price?: MarketPrice); * JobSetting — SQLAlchemy-модель, живёт через metadata Base. segno остался в backend/pyproject.toml и больше нигде не используется — снятие зависимости требует пересборки лока, поэтому отдельным PR. ruff clean, 4974 passed / 37 skipped.	2026-08-29 15:59:54 +03:00
bot-backend	bf3214b9e4	fix(tradein/scrapers): диагноз блока брался из текстовых маркеров чужой площадки, а не из HTTP-статуса (#3196) ... Сайдкар вообще не читал код ответа page.goto: страница классифицировалась только по маркерам, снятым с Авито. Домклик отдаёт статическую `403 | Домклик` на 26 624 байта, где нет ни одного такого маркера (замер прода 28.08.2026) — она уезжала наверх как валидный HTML, парсер не находил состояние, и прогон получал блок неизвестной природы. За 14 дней все 14 прогонов домклика легли с ban_kind='unknown'; у Яндекса счётчика blocked не было вовсе, поэтому ветка перевода прогона в 'banned' была недостижима по построению — ноль банов. - browser/server.py: статус целевой навигации сохраняется per-provider и доезжает в тело /fetch аддитивным ключом "status" (ключ "html" не тронут); 403/429 с маркерами челленджа больше не ждут PoW — ждать нечего, статическая страница сама себя не перезагрузит. Наверх идёт BanPageDetectedError, а не заглушка: вернув её контентом, воскресили бы #3045. - scraper_kit/browser_fetcher.py: BrowserFetcher.last_response_status + ban_kind_from_status (403/429 → platform, 5xx → infra, прочее → None). Поток управления не менялся: fetch() по-прежнему отдаёт str. - domclick: DomClickBlockedError несёт .status — один тип исключения на маркер-детект и на сбой фетча разводится без размножения типов; прогон передаёт перепись диагнозов в mark_backfill_finished. - yandex: появился счётчик blocked, оживляющий ветку бана. Серии блоков и промахов парсера считаются РАЗДЕЛЬНО: иначе четыре промаха плюс один 403 пятым давали 'banned' с переписью {platform: 1}. - cian: ban_kinds наполняется только диагностируемым статусом. HTTP 200 с пустым разбором — дрейф разметки на нашей стороне, а не отказ площадки; записав его блоком, мы бы штамповали фиктивные баны у здорового источника (13 done против 1 banned за 14 дней). Инвариант: непустой ban_kinds ⟺ виден ответ 403/429/5xx. Значения остаются в пределах CHECK scrape_runs.ban_kind. Известный пробел: шов providers/domclick/detail.py `blocked.status = status` тестами не покрыт — существующие домкликовые тесты подают исключение готовым моком и боевой fetch_detail не исполняют.	2026-08-28 23:21:54 +03:00
bot-backend	5be64c6688	fix(tradein/scrapers): хранилище авторизованной сессии Яндекс.Недвижимости (#3195)	2026-08-28 19:02:05 +00:00
bot-backend	bdb9b64b03	Merge pull request 'fix(tradein/domclick): исчерпание пула прокси помечалось как отказ сбора (#3118)' (#3174) from fix/3118-domclick-no-proxy into main	2026-08-27 22:03:56 +00:00
bot-backend	ade1a065d6	fix(tradein/domclick): исчерпание пула прокси свипа теперь infra-бан, не отказ сбора ... NoProxyAvailableError поднимается из BrowserFetcher.__aenter__ (_acquire_lease) ДО первого HTTP-запроса, когда пул прокси пуст — это НАША инфраструктура, не блокировка площадкой. У run_avito_full_load/run_cian_full_load/run_yandex_full_load уже есть выделенный except NoProxyAvailableError -> mark_banned(ban_kind='infra'), у run_domclick_city_sweep его не было: исключение проваливалось в общий except Exception внутри SERP-фазы, _scraper_ref оставался пустым, и честный статус ниже видел "0 лотов + errors>0" -> mark_failed("fetch errors — 0 listings") с ban_kind=NULL. Прод-факт: run 5023 (27.08) умер за 51 мс, errors_count=1, ban_kind=NULL — неотличимо от честного отказа сбора площадкой. Добавлен except NoProxyAvailableError перед generic except Exception (порядок важен: класс — подкласс RuntimeError). Обработчик зеркалит avito/cian/yandex: mark_banned + ban_kind_of_exception(exc) (даёт BAN_KIND_INFRA), и сохраняет унаследованный чекпоинт (skip_buckets) вместо потери его на нашем же отказе. Тест test_3118_domclick_no_proxy.py проверен на обратимость: без обработчика падает (mark_failed вместо mark_banned), с обработчиком — проходит.	2026-08-28 00:54:48 +03:00
bot-backend	dc793e8701	fix(tradein/yandex): чекпоинт combo ставился до save_listings, не после ... _on_combo в run_yandex_city_sweep делал done_combos.add(combo_label) ДО вызова save_listings. Отказ save_listings перехватывается (осознанно — одна упавшая единица не должна ронять весь sweep) и логируется, но combo уже был отмечен пройденным и уходил в heartbeat done_buckets. Следующий resume брал skip_combos из done_buckets (членство в множестве — само по себе корректно, не трогал) и пропускал этот combo навсегда: молча, прогон завершался штатно, просто сегмент выдачи не собирался никогда. Тот же инвариант "отмечаем пройденным только после успешного save", что уже есть у страницы в run_avito_newbuilding_sweep (_saved_ok), якоря в run_avito_city_sweep (_anchor_ok) и бакета в run_cian_full_load (_mark_bucket) — применил к combo. Heartbeat пишется в любом случае (и при отказе save тоже), иначе reap_zombies посчитает живой прогон мёртвым. Тесты: test_3170_yandex_combo_checkpoint.py — combo с упавшим save не попадает в done_buckets, успешный (включая пустую выдачу) — попадает. Обратимость проверена: с возвращённым дефектом (git stash) первый тест красный, со снятым — зелёный вместе с существующим test_3074_yandex_ sweep_checkpoint.py (6/6).	2026-08-28 00:48:55 +03:00
bot-backend	5a410687ac	feat(tradein/scraper): чекпоинты для avito_newbuilding_sweep — страница как единица (#3074) ... Последний длинный свип без возобновления: при обрыве прогон начинался с первой страницы, а собранное терялось целиком — save_listings вызывался один раз на весь sweep. Единица возобновления — страница выдачи, по образцу якорей в city sweep. `_paginate_sweep`/`fetch_newbuildings` получили `start_page` (уже собранные страницы не запрашиваются) и колбэк `on_page`, который вызывается только после того, как страница пройдена до конца. Сохранение стало постраничным, номера пройденных страниц копятся в `scrape_runs.counters.done_buckets` мержем через `update_heartbeat`. Два инварианта, без которых фича вредна: 1. В чекпоинт попадает только страница, чьи лоты СОХРАНЕНЫ. Отказ save_listings перехвачен и прогон продолжается, но отметить такую страницу пройденной значило бы, что следующий прогон её пропустит и объявления оттуда не соберутся никогда — молча, потому что прогон завершится штатно. 2. Подхват начинается с ПЕРВОЙ несобранной страницы, а не с max+1. Дыра в чекпоинте возможна ровно из-за п.1, и max+1 перепрыгнул бы её навсегда. Страницы после дыры перечитаются — это дешевле потери и безопасно, повторная запись схлопывается по dedup_hash. Оба инварианта закрыты тестами, которые падают при их нарушении.	2026-08-28 00:10:56 +03:00
bot-backend	26cd8dbe34	fix(tradein/avito): повтор после блока терял прокси и уходил с адреса машины ... Обе ветки повтора в `fetch_detail` — 403/firewall и 429 — пересоздавали эфемерную сессию вызовом `_build_detail_session()` БЕЗ `config`. Прокси kit-версия читает только из `config.scraper_proxy_url`, поэтому такая сессия уходила напрямую. Замысел ветки прямо обратный, он записан в её же комментарии: «эфемерная свежая сессия (новый CONNECT-туннель = свежий exit-IP)». Ветка вообще исполняется только при backconnect=True, а он вычисляется как «задан config.scraper_proxy_url» — то есть в момент вызова достоверно известно, что прокси есть, и он терялся. ПОЧЕМУ НЕ БЫЛО ВИДНО. Пока адрес самой машины не был заблокирован, прямой повтор часто срабатывал, и подмена канала выглядела как успех. Замер 27.08 из прод-контейнера, один и тот же URL Авито: через прокси — 200, 3.3 МБ страницы напрямую — 429, «доступ ограничен», firewall С этого момента каждый повтор после блока обречён. Обогащение avito_detail_backfill по суткам: 21-25.08 — 178/129/147/138/111, 26.08 — 23, 27.08 — 0 при 25 блоках. Обвал начинается ровно с окна, в котором сменился адрес машины. Тот же класс ошибки чинили в #2330 для build_warmed_session; в пути повтора он оставался. Три теста: обе ветки на месте (страховка от проверки пустоты), ни одна не строит сессию без config, и отдельно доказано, что без config прокси в сессии действительно нет. Проверил красноту на старом коде — падает с точным текстом. Прогон: 107 тестов scrapers зелёные, ruff чист. Refs #3034, #3045	2026-08-27 15:33:29 +03:00
bot-backend	ede5653aba	feat(tradein/domclick): чекпоинты для city_sweep — корзина как единица возобновления (#3118, #3074) ... Прод-факты #3118: QRATOR рубит свип внутри 1-2-й корзины при любом старте (buckets_completed ≤ 1 из 6), banned-прогоны собирают 59–1815 лотов. Сдвиг #2854 лишь распределяет потери; чекпоинт превращает случайную ротацию в систематический обход — шесть прогонов закрывают шесть корзин. Моё раннее «домклику чекпоинтить нечего» (замер в #3074 по средним 3 мин) опровергнуто данными #3118 — этот коммит исправляет тот вывод кодом. Зеркально yandex-чекпоинту (#3074): провайдер — skip_buckets + имена завершённых корзин + гард «цепочка накопила все 6» (честный no-op); buckets_total сжимается до объёма ЭТОГО прогона; пайплайн — done_buckets = унаследованное ∪ завершённое, heartbeat с мержем jsonb до финализации; планировщик — generic _pick_resume (#2845). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 16:52:44 +05:00
bot-backend	3c315b5105	fix(tradein/scheduler): boot-reap виден и при нуле — молчащий механизм неотличим от неподключённого (#3122) ... Первая живая приёмка #3122: деплоевский startup-reap успел снять зомби раньше, boot-reap отработал с нулём — и не оставил НИКАКОГО следа исполнения. Ноль — штатный исход, но «сторож, молчащий при нуле» — это слепая зона по построению: оборванную проводку не отличить от чистого прода. INFO-строка при нуле, warning при снятых — как было. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 14:33:06 +05:00