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;