From f1bad53de7e21b346fd436e1264bf7218905fb51 Mon Sep 17 00:00:00 2001 From: bot-backend Date: Thu, 17 Sep 2026 16:41:15 +0300 Subject: [PATCH] =?UTF-8?q?feat(trade-in):=20=D0=B2=D0=B5=D1=80=D0=BD?= =?UTF-8?q?=D1=83=D1=82=D1=8C=20=D0=B4=D0=BE=D0=BC=D0=BA=D0=BB=D0=B8=D0=BA?= =?UTF-8?q?-=D1=81=D0=B2=D0=B8=D0=BF=D1=8B=20=D0=9C=D0=BE=D1=81=D0=BA?= =?UTF-8?q?=D0=B2=D1=8B=20=D0=B8=20=D0=BE=D0=B1=D0=BB=D0=B0=D1=81=D1=82?= =?UTF-8?q?=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Миграция 308 выключила их потому, что свип копил лоты в памяти и сохранял одним save_listings после всех шести корзин: снятие по watchdog теряло всё собранное, а чекпоинт при этом помечал корзины пройденными. На выдаче размером с Москву (около 23 690 лотов вторички против 6 300 у ЕКБ) снятие было гарантировано, и итоговый сбор равнялся нулю навсегда. PR #3592 это снял: save_listings зовётся из колбэка on_bucket после каждой успешной корзины, туда же переехал чекпоинт, и корзина без сохранённых строк в него не попадает. interval_days = 1 вместо 3: полный проход Москвы в одно окно watchdog'а по-прежнему не помещается (замер run 7344 — 2 корзины из 6 за два часа). Добор идёт ротацией стартовой корзины плюс skip_buckets из чекпоинта, и при суточном такте шесть корзин закрываются примерно за трое суток против девяти при трёхсуточном. Корпус живёт 14 суток, девять не оставляли бы запаса на пропуски из-за QRATOR-банов. watchdog_sec намеренно не задаётся: override в коде есть, но поднимать таймаут до замера нечем обосновать — с инкрементальным сохранением ранний снос перестал быть потерей, а длинный прогон дольше держит один из двух узлов affinity='any'. Окна не меняются: Москва 0-3, область 9-12, ЕКБ 3-6 — ни одно не содержит двух домклик-строк. Проверено сухим прогоном на проде под ROLLBACK: UPDATE 2, обе строки enabled=t с interval_days=1, ЕКБ-строка не затронута. Claude-Session: https://claude.ai/code/session_01NQb6WeJtagZwZnUsSjDizs --- ...ck_msk_reenable_after_incremental_save.sql | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 tradein-mvp/backend/data/sql/326_domclick_msk_reenable_after_incremental_save.sql diff --git a/tradein-mvp/backend/data/sql/326_domclick_msk_reenable_after_incremental_save.sql b/tradein-mvp/backend/data/sql/326_domclick_msk_reenable_after_incremental_save.sql new file mode 100644 index 00000000..f0be049a --- /dev/null +++ b/tradein-mvp/backend/data/sql/326_domclick_msk_reenable_after_incremental_save.sql @@ -0,0 +1,56 @@ +-- 326_domclick_msk_reenable_after_incremental_save.sql +-- Вернуть домклик-свипы Москвы (77) и области (50) — причина выключения устранена. +-- +-- Apply after: 325_listing_source_snapshots_change_only_comment.sql +-- +-- WHY: +-- Миграция 308 выключила эти строки: свип копил лоты в памяти и сохранял их ОДНИМ +-- save_listings после всех шести корзин, поэтому снятие по watchdog теряло всё +-- собранное, а чекпоинт при этом помечал корзины пройденными. На выдаче размером с +-- Москву (≈23 690 лотов вторички против ≈6 300 у ЕКБ) снятие было гарантировано, и +-- итоговый сбор равнялся нулю навсегда. +-- +-- PR #3592 это снял: save_listings зовётся из колбэка on_bucket сразу после КАЖДОЙ +-- успешной корзины, туда же переехал чекпоинт — done_buckets теперь означает +-- «собрано И сохранено». Снятие по watchdog больше не теряет собранное, а корзина +-- без сохранённых строк в чекпоинт не попадает. Тем же колбэком добавлена +-- кооперативная отмена по корзинам (раньше is_cancelled проверялся только перед +-- SERP-фазой, и повисший свип нельзя было снять три часа). +-- +-- interval_days = 1, а не 3 как было: полный проход Москвы в одно окно watchdog'а +-- по-прежнему НЕ помещается (замер run 7344: 2 корзины из 6 за два часа). Механизм +-- добора — ротация стартовой корзины (start_bucket_index = run_id % 6) плюс +-- skip_buckets из чекпоинта: каждый прогон берёт корзины, которых ещё нет в +-- done_buckets. При суточном такте шесть корзин закрываются примерно за трое суток, +-- при трёхсуточном — за девять, а корпус живёт 14 суток (LISTINGS_FRESH_DAYS). +-- Девять суток на полный оборот не оставляли бы запаса на пропуски из-за +-- QRATOR-банов. +-- +-- watchdog_sec НЕ задаётся намеренно. Override в коде есть (PR #3592, читается из +-- default_params обоими хендлерами), но поднимать таймаут до замера нечем +-- обосновать: с инкрементальным сохранением ранний снос перестал быть потерей, а +-- более длинный прогон дольше держит один из ДВУХ узлов provider_affinity='any' +-- (id 13 и 14), за которые конкурирует cian. Сначала смотрим реальный выход за +-- прогон, потом решаем про таймаут. +-- +-- Окна не меняются: Москва 0-3, область 9-12 (разведены миграцией 307), ЕКБ 3-6. +-- Ни одно окно не содержит двух домклик-строк — это условие, за нарушение которого +-- 17.09 ЕКБ-свип run 7339 отбился 'banned' за 0 секунд. +-- +-- Чекпоинт прогонов 7333/7344 сбрасывать не нужно: у обоих buckets_completed пуст, +-- они были задрейнены деплоем ещё до первой завершённой корзины. +-- +-- ИДЕМПОТЕНТНОСТЬ: UPDATE ... WHERE source IN (...) — повторный прогон пишет те же +-- значения. next_run_at не трогаем: планировщик посчитает его сам по окну, а явная +-- простановка здесь разъехалась бы с реальным временем применения миграции. + +BEGIN; + +SET LOCAL lock_timeout = '5s'; + +UPDATE scrape_schedules + SET enabled = true, + default_params = jsonb_set(default_params, '{interval_days}', '1'::jsonb, true) + WHERE source IN ('domclick_city_sweep_moskva', 'domclick_city_sweep_moskovskaya_oblast'); + +COMMIT; -- 2.45.3