tradein-mvp/backend/data/sql/308_domclick_msk_disable_until_incremental_save.sql

@@ -0,0 +1,60 @@
+-- 308_domclick_msk_disable_until_incremental_save.sql
+-- Выключить домклик-свипы 77/50: в текущем виде они по построению не могут ничего собрать.
+--
+-- Apply after: 307_domclick_msk_window_no_collision.sql
+--
+-- WHY (замерено 17.09.2026 одиночным прогоном, без соседей по сайдкару и пулу):
+--
+--   run 7344, source='domclick_city_sweep_moskva', прокси id=13, стартовал 06:12:48.
+--   За ДВА часа пройдено 2 бакета из 6: 'st' занял 34.2 мин, '1' шёл 86+ мин и не
+--   закончился. Watchdog прогона — 11100 с (3 ч 05 мин).
+--
+--   Это НЕ одновременность и НЕ блок площадки: прогон был единственным, узел не банился,
+--   QRATOR-блока в логе нет. Причина структурная — ДомКлик режет offset на 2000, поэтому
+--   на больших выдачах скрейпер бисекцией делит диапазон по цене на листья, и КАЖДЫЙ лист
+--   пагинируется отдельно. У Москвы ≈23 690 лотов вторички против ≈6 300 у ЕКБ, листьев
+--   кратно больше. А формула watchdog'а (pipeline.run_domclick_city_sweep) считает число
+--   фетчей как _DOMCLICK_NUM_BUCKETS * pages = 6 * 100 и объём выдачи не учитывает вовсе:
+--   11100 = 600 * (6 + 12) + 300. Она линейна по pages, поэтому уменьшение
+--   pages_per_anchor урезает и сам watchdog — лечения не даёт.
+--
+--   Хуже, чем просто «не успевает». _domclick_phase — «единственная citywide-фаза:
+--   fetch_city + save»: лоты копятся в памяти и сохраняются ОДНИМ save_listings после
+--   всех шести бакетов. Снятие фазы по watchdog (asyncio.wait_for → TimeoutError) теряет
+--   всё собранное. При этом чекпоинт #3118 пишется ПОСЛЕ этого, из живой ссылки на
+--   скрейпер: done_buckets = унаследованное ∪ _s.completed_buckets. То есть бакеты
+--   помечаются пройденными, хотя ни одна их строка не сохранена, и следующий прогон
+--   пропускает их через skip_buckets. Два-три таких прогона закрывают чекпоинт целиком —
+--   итоговый сбор по 77/50 равен нулю навсегда.
+--
+--   Пока строки включены, вред не нулевой: каждые трое суток каждая забирает один из ДВУХ
+--   узлов с provider_affinity='any' (id 13 и 14) на три часа и не отдаёт ничего. 17.09
+--   из-за этого ЕКБ-свип run 7339 отбился 'banned' за 0 секунд, пока оба узла держали
+--   московские прогоны. Выключение восстанавливает статус-кво ЕКБ.
+--
+-- ЧТО НУЖНО ДЛЯ ВОЗВРАТА (не в этой миграции — это правка кода в scraper-kit):
+--   1. Инкрементальное сохранение по бакетам: save_listings внутри цикла fetch_city
+--      (колбэк on_bucket, как у run_cian_full_load), чтобы снятие по watchdog сохраняло
+--      собранное, а чекпоинт перестал врать.
+--   2. Watchdog, зависящий от объёма выдачи (snippetsCount), а не только от pages.
+--   3. Кооперативная отмена по бакетам: runs.is_cancelled сейчас проверяется только ПЕРЕД
+--      SERP-фазой, поэтому повисший свип нельзя снять до watchdog'а.
+--   4. При возврате — сбросить унаследованный чекпоинт (counters.done_buckets прогонов
+--      7333/7344), иначе resume пропустит бакеты 'st' и '1', по которым ничего не сохранено.
+--
+--   ЕКБ-строка 'domclick_city_sweep' НЕ трогается: её выдача помещается в watchdog
+--   (run 7219 16.09 — 70 минут, 6372 seen / 237 new), у неё дефект не проявляется.
+--
+-- ИДЕМПОТЕНТНОСТЬ: UPDATE ... WHERE source IN (...) — повторный прогон переписывает то же
+--   значение. Возврат — ручным UPDATE enabled = true после правок выше, либо новой
+--   миграцией.
+
+BEGIN;
+
+SET LOCAL lock_timeout = '5s';
+
+UPDATE scrape_schedules
+   SET enabled = false
+ WHERE source IN ('domclick_city_sweep_moskva', 'domclick_city_sweep_moskovskaya_oblast');
+
+COMMIT;