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;