3 commits

Author	SHA1	Message	Date
bot-backend	b64e824e17	fix(tradein/sber): сторож мерит отставание загрузки, а не календарь (#2846) ... Порог свежести якоря был недостижим по построению. period_month — метка ПЕРВОГО числа месяца, поэтому возрасту ≥30 уже на закрытии месяца; плюс лаг публикации источника. За 31 сутки прямых наблюдений монитора (07-13…08-12, scrape_runs.counters) возраст лежал в 46..76 и ни разу не опускался ниже 46 — при пороге оценщика 35. Сторож был истинным 100% времени с рождения таблицы и нёс ноль бит: при живом источнике и при мёртвом загрузчике он писал одно и то же. Второй порог (монитор, 60 = 35 + запас 25) не лучше: он лежит ВНУТРИ рабочего диапазона. Обещание миграции 212 («такт 7 ⇒ потолок возраста 53 < 60») прод ОПРОВЕРГ — 2026-08-12 возраст 72 при полном прогоне загрузки 08-06; двенадцатые сутки подряд ERROR при исправной загрузке. Потолок 53 держался бы, только если бы источник публиковал строго помесячно. Что теперь. Загрузчик тянет ВСЮ серию (limit=1000&offset=0), поэтому после прогона с errors=0 AND upserted>0 наш max(period_month) равен максимуму источника ПО ПОСТРОЕНИЮ. Значит вопрос «отстали ли мы» = «давно ли был последний ЗАВЕДОМО ПОЛНЫЙ прогон», и он не зависит от возраста периода. Порог — 2 такта самой загрузки, читается из scrape_schedules.default_params.interval_days, то есть из той же строки, по которой планировщик считает next_run_at: разъехаться с тактом он не может. status='done' за успех не считается — прогон id=37 имеет done при {errors: 9, upserted: 0}. Табло спрашивается тем же порядком, что у оценщика (SBER_COEFF_DASHBOARDS), потому что max() по таблице маскирует отставшее табло: real_estate_deals 2026-06, dinamika-tsen-obyavlenii 2026-05. Два порога сведены удалением: settings.sber_index_max_age_days и per-estimate warning в estimator убраны, свежесть считает ровно одно место. fetched_at больше не переписывается апсертом. Забор идёт всей серией, поэтому fetched_at = now() в DO UPDATE ставил одну метку всем 639 строкам, включая период 2017-01 — как признак свежести колонка была пуста. Теперь она означает «когда впервые увидели период», т.е. такт публикации источника станет измеримым. Ретроспективу это не возвращает: у уже лежащих строк метка 2026-08-06 и останется. Refs #2846	2026-08-13 00:25:53 +05:00
bot-backend	3e1b9a8b0d	fix(tradein): чинит такт загрузки СберИндекса — иначе новый ERROR стал бы ложной тревогой (#2674) ... Ревью PR #2681 опровергло исходную посылку по СберИндексу, и это подтвердилось на моих же числах (все 24 прогона монитора, read-only): 13-16.07 alert=1 age 73..76 latest=май 17.07 alert=0 age 46 latest=июнь ← день загрузки 18-31.07 alert=0 age 47..60 01-05.08 alert=1 age 61..65 Загрузка ходила раз в 28 дней и приносила период на месяц новее, возраст считается от первого числа покрытого месяца → пол 46, потолок 74, порог 60 ВНУТРИ диапазона. Тревога срабатывала 14 суток из 28 без всякого застоя источника: девять срабатываний были замером нашего собственного такта. Поднятие до ERROR без этой правки завело бы ежедневное ложное событие две недели в месяц. Миграция 212 переводит sber_index_pull на недельный такт (потолок ≈53 при пороге 60, запас 7 суток) вместо поднятия порога до 75 (запас 1 сутки — ломается от любого сдвига окна). Цена: 9 запросов в неделю вместо 9 в 28 дней к публичному sberindex.ru/api/sowa; прогон 4 секунды, 0 ошибок за всю историю. Дополнительно по ревью: - поллер Росреестра: ветка «файл найден в листинге, но HEAD не отдал zip» → ERROR (ровно поведение старой Bitrix-заглушки) + вписана в таблицу уровней; - тестовый харнесс закрывает клиент событий (фоновый поток на каждый тест). Refs #2674	2026-08-06 02:53:26 +05:00
bot-backend	07275c3c97	feat(tradein): монитор свежести СберИндекса (audit п.1) ... Добавляет sber_freshness_monitor по образцу deals_freshness_monitor: staleness данных СберИндекса теперь видна на MONITOR-частоте, а не тонет в per-estimate warning'ах estimator._load_sber_index_series (#audit-5a). - app/tasks/sber_freshness_monitor.py: чистая evaluate_sber_freshness() (frozen-now, без БД) + check_sber_freshness() (один SELECT max(period_month) вторичного сегмента по региону, #R2-H1 фильтр как в эстиматоре; WARNING при stale, mark_done при алерте — это монитор, не сбой; mark_failed только при пустой таблице). - app/services/product_handlers.py: _job_sber_freshness_monitor + Handler в build_product_handlers (run_in_executor, как deals-монитор). - data/sql/180_seed_sber_freshness_monitor.sql: seed scrape_schedules (enabled, daily 09:00-10:00 UTC, lag_allowance_days=25). - tests/test_sber_freshness_monitor.py: frozen-now (fresh/stale/границы) + FakeDB (fresh/stale/empty/кастомный lag) + свойства миграции + registry. Порог алерта: sber_index_max_age_days (35) + lag_allowance (25) = 60д. +25 — запас на инхерентный лаг публикации источника (1-2 мес), чтобы не шуметь на штатном отставании. Прод 2026-07-12: max=2026-05-01, age=72д > 60 → alert=1.	2026-07-12 23:27:35 +03:00