tradein-mvp/backend/data/sql/307_domclick_msk_window_no_collision.sql

@@ -0,0 +1,60 @@
+-- 307_domclick_msk_window_no_collision.sql
+-- Развести окна ДомКлика: областной свип не должен стартовать вместе с ЕКБ-свипом.
+--
+-- Apply after: 306_scrape_schedules_seed_domclick_msk.sql
+--
+-- WHY:
+--   Миграция 306 поставила 'domclick_city_sweep_moskovskaya_oblast' в окно 3-6 — РОВНО
+--   то же, где с самого начала сидит ЕКБ-строка 'domclick_city_sweep'. Планировщик
+--   домклик-джобы не сериализует: 17.09.2026 обе новые строки были заклеймлены в одну
+--   секунду (run_id 7333 и 7334, 05:00:55) и пошли параллельно.
+--
+--   Почему это плохо, без домыслов о причинности: два свипа ДомКлика делят ОДИН
+--   браузерный сайдкар и ОДИН пул. В минуты параллельного прогона tradein-browser
+--   держал 67% CPU, 1.67 из 2.5 ГиБ и 2297 PID, а часть запросов возвращалась как
+--   'Page.goto: Timeout 60000ms' и 'socket hang up' → HTTP 500. Узлов с
+--   provider_affinity='any' в пуле всего два (id 13 и 14) — их же берёт cian, так что
+--   параллельная пара домклик-свипов забирает оба.
+--
+--   ЧЕГО ЭТА МИГРАЦИЯ НЕ УТВЕРЖДАЕТ: что параллельность уронила сбор. Померить это по
+--   ходу прогона нечем — DomClickScraper.fetch_city копит лоты в память и сохраняет их
+--   ОДНИМ save_listings после обхода всех шести бакетов, инкрементального сохранения
+--   нет. Поэтому 'ноль строк в listings за 45 минут' — нормальное состояние середины
+--   прогона (здоровый одиночный ЕКБ-свип 16.09, run 7219, тоже не писал ничего 70 минут
+--   и затем положил 6372 seen / 237 new). Разводим окна по ресурсной причине выше, а не
+--   по выводу из этой метрики.
+--
+--   Новое окно области — 9-12: там нет НИ ОДНОЙ домклик-строки (домклик-джобы всего
+--   три: 'domclick_city_sweep' 3-6, 'domclick_city_sweep_moskva' 0-3 и
+--   'domclick_detail_backfill' 15-18). Москва остаётся в 0-3 — она и так единственный
+--   домклик в этом окне.
+--
+--   next_run_at выставляется ЯВНО и разнесён: без этого строки сохранили бы значения,
+--   посчитанные при первом клейме (Москва 20.09 01:46, область 20.09 04:11), а 04:11
+--   попадает внутрь ЕКБ-окна 3-6 — та же коллизия повторилась бы через трое суток.
+--
+--   Скобки + 'AT TIME ZONE UTC' на РЕЗУЛЬТАТЕ, а не только внутри: next_run_at —
+--   timestamptz, а date_trunc от naive-времени вернул бы timestamp без зоны, и приведение
+--   поехало бы по таймзоне сессии. Здесь обе стороны явные.
+--
+-- ИДЕМПОТЕНТНОСТЬ: UPDATE ... WHERE source = '...' — повторный прогон переписывает те
+--   же значения. enabled НЕ трогаем: если строку выключили вручную, она останется
+--   выключенной.
+
+BEGIN;
+
+SET LOCAL lock_timeout = '5s';
+
+UPDATE scrape_schedules
+   SET window_start_hour = 9,
+       window_end_hour   = 12,
+       next_run_at       = (date_trunc('day', now() AT TIME ZONE 'UTC')
+                             + interval '3 days 9 hours 30 minutes') AT TIME ZONE 'UTC'
+ WHERE source = 'domclick_city_sweep_moskovskaya_oblast';
+
+UPDATE scrape_schedules
+   SET next_run_at = (date_trunc('day', now() AT TIME ZONE 'UTC')
+                      + interval '3 days 0 hours 30 minutes') AT TIME ZONE 'UTC'
+ WHERE source = 'domclick_city_sweep_moskva';
+
+COMMIT;