196 commits

Author	SHA1	Message	Date
lekss361	dfe7910bb7	ДомКлик как четвёртый источник переливки московского сырья в listings (#3497)	2026-09-12 12:26:09 +00:00
bot-backend	70b1419cde	Merge remote-tracking branch 'forgejo/main' into fix/3471-scraper-log-levels	2026-09-12 14:36:08 +03:00
bot-backend	ac5b044f7e	fix(scrapers): ожидаемые исходы сбора (бан, пустой пул, капча) больше не error ... Скрапер один давал 3006 error-строк в сутки из ~3700 по всему Trade-In — ленту перестали читать, и настоящая поломка терялась в ней. Принцип: ожидаемый исход сбора (площадка забанила, пул прокси пуст, капча/недогруз, серия блоков перевалила порог circuit breaker) — это состояние работы против недружелюбного источника, а не инцидент. В error остаётся только неожиданное: изменившаяся вёрстка/схема (Cian markup change), просроченный токен ротации прокси (ASocks 401), неразобранное исключение. Переведено error -> warning в 9 файлах, 12 мест: "СТОП — пул прокси пуст" (avito/domclick/cian_history/yandex_newbuilding_sweep x2), "пул прокси исчерпан" (cian_session, cian_price_history, yandex_address_backfill), FAIL-CLOSED без здорового узла для source (proxy_egress), ABORT по счётчику подтверждённых блоков площадки (avito, domclick, yandex_detail_backfill). Оставлено error намеренно: cookie-алерты Cian/DomClick (#2658, #2674) — они рассчитаны именно на LoggingIntegration(event_level=ERROR) в scheduler_main.py и без него молчат по 37 дней; ABORT по смешанным/soft причинам без единого подтверждённого блока площадки (#3272, #2674/#3196) — это может быть наш баг, а не бан, сигнал сознательно не приглушали. GlitchTip: сентри-интеграция скрапера уже настроена как LoggingIntegration(level=INFO, event_level=ERROR) в scheduler_main.py — отдельной правки sentry_scrub.py не требуется, понижение уровня logger само убирает эти записи из GlitchTip. Итоговая FINISHED-строка со счётчиками (attempted/enriched/blocked/failed) уже существует в каждом detail_backfill — новую не добавлял. Refs #3471	2026-09-12 14:15:59 +03:00
bot-backend	9eb42607b9	feat(glitchtip): фоновая ретрай-доставка алерта в Telegram при отказе синхронной попытки ... GlitchTip не ретраит вебхуки (#3157) — is_sent проставляется безусловно сразу после HTTP-ответа приёмника. При отказе Telegram синхронная попытка отвечала 502 и текст алерта пропадал безвозвратно (TRADE-IN-3F7, 28.08.2026; сеть до Telegram с хоста теряет ~каждый четвёртый запрос — замер 12.09). 502 при отказе Telegram ОСТАВЛЕН как есть — он задуман осознанно (#3456) как честный сигнал отправителю. Меняется судьба самого текста: перед возвратом 502 доставка ставится в фон через starlette.background.BackgroundTask на самом JSONResponse (app.tasks.glitchtip_alert_retry.retry_forward_alert), а не через FastAPI BackgroundTasks-зависимость — та привязывает задачи только к ответу, который вернул сам хендлер, а `raise HTTPException` строит отдельный ответ в exception-мидлваре, и такая задача не выполнилась бы вовсе (воспроизведено тестом при первой попытке реализации). Celery в проекте нет: ни app/celery_app.py, ни зависимости celery в backend/pyproject.toml не существует — бутстрап полноценной очереди с воркером вне границ этой задачи (новый контейнер/брокер). Фон использует штатную "воркерную" ретрай-политику TelegramClient.send_message (5 попыток, backoff до 30s) плюс свой внешний потолок в 3 попытки, чтобы недоставляемый алерт не крутился вечно — при исчерпании сдаётся с ERROR-логом текста. Переиспользует существующее форматирование (_build_message) и общий клиент приложения, без дублирования и новых переменных окружения. Refs #3471, #3157	2026-09-12 14:11:01 +03:00
bot-backend	2467943200	feat(mera/лендинг): витрина показывает полосу расхождения −5…+20 %, плитку уверенности сменил замер 12.09 ... Владелец просит на витрине только сделки, где прогноз разошёлся с ценой ДКП в пределах от −5 % до +20 %. Фильтр живёт в продюсере (`select_rows`), поэтому таблица сверок и бегущая строка берут ОДИН набор, а не два. Чтобы страница от этого не начала врать: * `REJECTION_RULE` переписан. Прежняя формулировка («величина отклонения на отбор и отбраковку не влияет — иначе витрина показывала бы лучший хвост») после фильтра стала ложью ровно про то, чего опасалась, поэтому снята, а не смягчена. Новая называет полосу и говорит, что это отбор показательных строк, а не вся сверка. Границы в текст ПОДСТАВЛЯЮТСЯ из констант `BAND_MIN_ERR_PCT`/`BAND_MAX_ERR_PCT` — подпись не может разъехаться с фильтром, и это проверяется тестом. * Фильтр стоит в `select_rows`, а не в `build_row`: строка вне полосы остаётся кандидатом и попадает в `eligible`. Отбраковав её раньше, мы получили бы «показано 20 из 20 годных» — счётчик, из которого отбор не виден вообще. * Счётчики разъехались с подписью, и подпись поправлена: `eligible − written` больше не значит «столько не поместилось», в разницу входят отсеянные полосой. Под таблицей теперь «показано N строк из M собранных прогоном». * «В пределах 20 % — N из N» из подписи снято: при потолке полосы +20 счёт всегда выходил бы N из N и читался бы как замер попадания. Неработающая проверка читается как работающая. * Медиана по ВСЕЙ сверке (15,3 %, 325 сделок) в подписи осталась и теперь сторожится тестом: без неё разброс отобранной двадцатки читается как точность расчёта. * Полоса названа и в подписи ленты — она висит над первым экраном, её числа читают раньше любых оговорок блока «Точность». * Меньше лимита в полосе — показываем сколько есть, добора нет. Плитка «400 из 400 расчётов с пометкой „уверенность низкая“» заменена на свежий замер 12.09.2026 (engine=full, 290 сделок, медиана трёх пересборок с солями 11/22/33): «52,7 % сделок — расхождение в пределах ±20 %». Запись `confidenceLow` не удалена, а помечена снятой (прогон 29.08 на кластеризованной выборке) — до решения владельца. Оговорки новой величины называют три вещи, без которых она льстит: замер не point-in-time, разброс пересборок 46,2–56,6 %, и что медианное расхождение того же прогона (19,1 %) ВЫШЕ прежних 15,3 % от 31.08 — на странице два числа разных дат, и молчать о том, что свежий прогон вышел хуже, нельзя. `priceError` и `coverage` не тронуты. Сторож свежести теперь следит за ОБЕИМИ датами замеров, а не только за 31.08. Проверено: на проде из 20 сегодняшних строк витрины в полосу попадают 8 (40 %), что сходится с 35,5 % «доли в полосе» из бэктеста 12.09. Фальсификация: снятие фильтра руками красит 3 теста, ключевой — по значению ([44, 43, 41] вместо [44] на реальных строках прода +75,7 / −27,9 / +9,9 %). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 15:29:10 +05:00
bot-backend	ce9c45c3c2	feat(msk): импортёр знает Яндекс — город из адреса, ноль внешних вызовов ... Сбор Яндекса по Москве уже идёт, а лить его было нечем: в SOURCE_VIEWS стояли только cian и avito. Отбор Москвы у Яндекса не требует ни префикса округа (как у Циана), ни пред-геокода (как у Авито). Адрес приходит полным и нормализованным — «Россия, Москва, Коробейников переулок, 1», регион читается вторым компонентом. Замер по 21 393 карточкам первого прохода: во втором компоненте ровно ДВА значения, «Москва» 10 610 и «Московская область» 10 783, третьего не встречается. Новая Москва отдельным значением не приходит — Троицк и Зеленоград Яндекс кладёт под «Москва», что совпадает с кодом региона 77. Координаты, адрес и ссылка заполнены у 100% карточек, поэтому geom появляется сразу и ждать ночного `geocode_missing` не нужно. `--geocode` для yandex отклоняется так же, как для cian: квота нужна только Авито. `filter_by_okrug` заменён словарём CITY_FILTERS — источник либо сам говорит про город, либо его в словаре нет и без пред-геокода писать его нельзя. Поведение cian и avito байт в байт прежнее. `uv run python -m pytest tests/test_msk_raw_import.py` — 42 passed, ruff чист. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-12 02:19:44 +03:00
bot-backend	de5f4a32cd	fix(msk): сухой прогон пред-геокода падал на отсутствующей кэш-таблице ... Кэш `msk_raw.avito_geocode` создаётся только боевым прогоном (`geocode and not dry_run`), а читается безусловно. На проде это роняло `--dry-run` первым же запросом — UndefinedTable msk_raw.avito_geocode, то есть ломалась ровно та репетиция, ради которой сухой прогон и существует. Наличие отношения проверяется через `to_regclass`, а не ловится исключением: в Postgres упавший оператор кладёт транзакцию целиком, и except потребовал бы rollback посреди чужого батча. Замер после правки (500 карточек, прод): отобрано 458, область 7, не разрешено 35 (7%), геокод-вызовов 338 на 500 карточек — дедупликация адреса внутри страницы работает. Счётчики сходятся. Заодно выяснилось, что дневная квота DaData на подсказки — 200 000, а не 10 000: `stat/daily` на проде показывает suggestions remaining 200000 при нулевом расходе. Весь корпус (21 565 различных адресов) проходит за один заход, дробить на трое суток не нужно. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-11 18:51:38 +03:00
bot-backend	996b814919	feat(msk): пред-геокод московского Авито — город из слага, регион из КЛАДР ... У карточек Авито нет координат ни у одной из 50 335, а адрес — голая улица с домом («Варшавское ш.,62к1»). Сбор шёл по `/moskva_i_mo/`, поэтому Москву от области отделить было нечем: префиксный фильтр, работающий у Циана по округу, здесь отбросил бы 100% строк. Наивный матч адресов к `houses(77)` даёт ровно 0 совпадений — дома лежат как «ЮАО, р-н Даниловский, проспект Андропова, 18». Замер показал, что одного геокода мало: с констрейнтом «Москва + Московская» дом находится у 92% адресов, но верхний кандидат DaData расходится с реальным городом у 15% и почти всегда в пользу столицы. Недостающий сигнал лежал рядом и бесплатно — слаг города в `source_url` (`avito.ru/moskva/...`), заполнен у 100% карточек: 22 120 с `moskva`, остальное — подмосковные слаги. Поэтому город берётся из слага и сужает констрейнт, а регион — из КЛАДР ответа, не из слага: Новая Москва (Троицк, Щербинка, Коммунарка, Зеленоград) идёт своими слагами, но это регион 77. Регион 77 пишется в `listings` сразу с координатами и `geo_precision='house'`, поэтому строки попадают в radius-подбор аналогов без ожидания `geocode_missing`. Регион 50 не пишется, а копится строкой в кэше `msk_raw.avito_geocode` — до появления региона в реестре. Кэш ключуется слагом и нормализованным адресом, отрицательные ответы тоже кэшируются, так что повторный прогон внешний сервис не дёргает. `geocode_cache` приложения не тронут — там другой ключ. `--allow-unfiltered` без `--geocode` остаётся прежним аварийным режимом. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-11 18:16:18 +03:00
bot-backend	491f7d43ac	feat(msk): полосы цен по округам Москвы и СберИндекс по региону запроса ... ПОЛОСЫ. deal_city_price_bands ключевались парой (region_code, city), а у всех 212 937 московских сделок city равен «Москва» — одна полоса 34221..718870 на весь город при четырёхкратном разбросе цены между округами. Ключом стало выражение COALESCE(NULLIF(raw_payload->>'src_city',''), city): округ заполнен у 198 600 сделок (93.27%), 197 различных значений. Выражение живёт в одном модуле app/services/deal_city_key.py и используется и derivation, и всеми тремя читающими местами — разъехавшийся ключ означал бы мёртвые строки таблицы. Поиск полосы двухступенчатый: строка округа, затем строка города, затем глобальные константы. Без второй ступени окно между деплоем и первым ночным рефрешем уронило бы московские сделки на калибровку Екатеринбурга (пол 50 000 против 34 221). Замерено на проде: двухступенчатый поиск оставляет 208 677 сделок из 212 937, одноступенчатый — 207 594. Потолок полосы стал региональным и собирается из именованных констант, общих у SQL и питоновского двойника: GREATEST(800000, LEAST(p99.99, 6 x медиана)). Регион 66 получает те же 800 000, регион 77 — 1 766 742, поэтому дорогие округа (Пресненский p99 = 1 198 694) больше не срезаются потолком. СБЕРИНДЕКС. Временная поправка замороженных ДКП-сделок была прибита к ряду «Свердловская область» и применялась в том числе к московским сделкам. Замер: средневзвешенный по 69 138 московским сделкам за 12 месяцев фактор равен 1.0313 по свердловскому ряду против 1.0917 по московскому — коридор занижен на 5.9%, и он не advisory: участвует в clamp headline, radius-floor и Tier-C gate. Ряд теперь резолвится по региону запроса, регион вне карты получает общероссийский ряд, а не чужой региональный. Монитор свежести следит за обоими рядами. Пропажа чужого ряда больше не подавляет вердикт по ряду региона по умолчанию, ошибка драйвера откатывает сессию, счётчики заполняются и в ветке раннего выхода. РЕГИОН 66 БАЙТ-В-БАЙТ. src_city пуст у всех 108 623 его сделок, поэтому обе ступени ключа совпадают; популяция derivation и все 383 строки полос не изменились, потолок остался 800 000, ряд СберИндекса тот же. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-11 01:37:48 +03:00
bot-backend	b1727ca39c	feat(msk): импорт сырья по Москве в listings и region-aware геокодирование ... Три куска, каждый нужен, чтобы поиск и оценка по Москве заработали end-to-end. 1. Импортёр msk_raw -> listings (app/tasks/msk_raw_import.py). Переиспользует штатный save_listings из кита: писатель уже параметризован регионом, свой не нужен. payload в msk_raw — сериализованный ScrapedLot один в один, так что импорт сводится к сборке модели и вызову писателя. Москва отбирается по префиксу административного округа в адресе, а не по bbox. Причина: адрес Циан не содержит города, а границы региона 77 захватывают ближний пояс области. Замер по проду: с округом 35 552, все внутри bbox 77; без округа внутри bbox 17 576 — это область. Отдельно отсекаются 212 карточек с адресом «Екатеринбург (Cian)», артефакт парсера. listing_segment ПЕРЕСЧИТЫВАЕТСЯ перед записью, а не копируется из payload. Кит ставит novostroyki по одному наличию offer.newbuilding.id. Замер по всем 60 464 карточкам: is_from_developer=true у НУЛЯ, false у 29 000, отсутствует у 31 464. Застройщик не продаёт ни одной карточки корпуса. В проде есть гвард (estimator.py): в аналоги идут строки только с listing_segment IS NULL или 'vtorichka' — копирование метки как есть выбросило бы 29 000 строк из подбора. Авито импортируется только с явным --allow-unfiltered: в его адресе нет ни города, ни округа, координат нет ни у одной из 50 335 карточек, отличить область от Москвы нечем. Прогон на проде: прочитано 60 464, записано 35 552, все с геометрией, 35 182 привязаны к дому, создано 10 960 домов. Повторный проход строки не дублирует — idempotency на dedup_hash, проверено. 2. Подсказки адреса стали региональными (geocoder.suggest, api/v1/geocode). Раньше suggest вообще не принимал регион: DaData звалась с жёстким region='Свердловская', Nominatim — с viewbox 66-го и bounded=1. Московский адрес давал ПУСТОЙ список молча, без ошибки; в коде это уже было описано как известный баг. Механику по регионам переиспользовали из geocode(), вторую не писали. Кадастровый тир для не-66 не зовётся: он на ЕКБ-данных. 3. Оценка перестала геокодировать Москву свердловским скоупом (estimator). geocode() звалась без региона, то есть с дефолтом 66, и московский адрес возвращал бы пустую оценку с причиной address_not_geocoded даже с рабочими подсказками. Регион запроса определяется по координатам через реестр, затем по city_hint, затем дефолт. Fast-path клиентских координат стал региононезависимым: OBLAST66_BBOX и REGIONS[66].bbox_region совпадают байт-в-байт, поэтому для 66 поведение прежнее, добавились координаты Москвы. Регресс-нейтральность по Свердловской области — главный критерий всех трёх кусков. Тесты: 1160 passed по затронутым областям. Известные ограничения. Границы 77 захватывают ближний пояс области, Химки резолвятся в Москву. У региона 77 нет ни одного тира обогащения, оценка поедет на аналогах и сделках. Ценовая полоса по Москве одна на весь город. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-10 18:50:37 +03:00
bot-backend	1d9adb4a24	feat(tradein/estimator): deal_city_price_bands по ключу (region_code, city) — миграция 298, refresh per-region, потребители (#3051 sub-PR B) ... После импорта 212 937 московских ДКП (region_code=77) region_stats refresh'а (p1 для tier region_fallback) считался бы по пулу 66+77 и поднял бы floor ~250 малым городам области. Ключ bands становится (region_code, city): миграция 298 (колонка DEFAULT 66, смена PK через DO-guard, re-seed per-region, ЕКБ-исключение только для 66, doc_type=ДКП), тот же SQL в refresh-джобе, estimator/backtest читают bands по паре. Для 66 набор строк байт-идентичен прежнему (ревью двумя линзами).	2026-09-09 02:25:47 +03:00
lekss361	e0bef636e6	feat(tradein): bulk-дампы открытых данных ФНС по юрлицам + lookup по ИНН (#3429)	2026-09-08 22:29:10 +00:00
lekss361	50f0674977	feat(tradein): слой ДТП из dtp-stat.ru в PostGIS + радиусные агрегаты (#3428)	2026-09-08 22:10:56 +00:00
bot-backend	1f3566c466	merge main в feat/mera-cbr-macro — оба handler'а (frt_mkd_load + cbr_macro_pull) в реестре	2026-09-09 00:43:13 +03:00
bot-backend	2abab8218e	feat(mera): макро-ряды ЦБ РФ — ипотека по субъектам и ключевая ставка ... Три XLSX ЦБ (выдачи, ставка, задолженность) в разрезе субъектов, помесячно с 01.2019, + ключевая ставка через SOAP DailyInfo.asmx (метод KeyRate; GET на нём не работает, только POST). Всё анонимно, без ключа. Таблицы: cbr_mortgage_series (region, period_month, series) и cbr_key_rate. fetched_at НЕ обновляется в DO UPDATE — по уроку #2846 колонка значит «когда мы ВПЕРВЫЕ увидели период» и по ней меряется такт публикации источника. Раскладка листов у ЦБ РАЗНАЯ, и это ловушка: в 02_11/02_13 шапка периодов в строке 3 текстом («Январь 2019»), а в 02_14 (задолженность) — уже в строке 2 и настоящими datetime. С захардкоженным индексом строки серия debt_rub молча давала НОЛЬ строк при зелёных тестах. Теперь строка шапки ищется динамически: берётся строка с наибольшим числом распознанных периодов среди первых шести. Проверено на живых файлах: каждая из трёх серий даёт 8 736 точек (96 территорий × 91 месяц, 01.2019–07.2026); по Свердловской области 91 месяц, последняя ставка 11.49. estimator.py не тронут: как ипотечная ставка войдёт в оценку — отдельное продуктовое решение, этот PR только про данные. Миграции 292 (таблицы) и 293 (сид расписания, enabled=false, interval_days 7). Новая зависимость: openpyxl.	2026-09-09 00:33:12 +03:00
bot-backend	8aca820a46	feat(mera): загрузчик реестра МКД АИС ФРТ → обогащение houses ... Открытые данные АИС ППК «ФРТ» (бывш. Реформа ЖКХ), node 110 = реестр МКД региона 66: 41 790 строк, houseguid (ФИАС GUID) заполнен на 100% → join к houses.gar_house_guid без канонизации адреса. Анонимный GET, без ЕСИА. Заполняет ТОЛЬКО NULL-поля houses: year_built, material_walls, material_floors, total_floors, entrances, is_emergency, flat_count, heat_supply_type, gas_supply_type, hot_water + новые area_land, foundation_type, elevators_total. Замер по ЕКБ: wall_material 92.5% (было 75% от ДОМ.РФ), built_year 92.0% (было 86%), area_land 86.8% и is_emergency — признаков, которых не давал ни один из текущих источников. Осознанно НЕ мапится: - project_type → series_name: свободный текст и фактически дубль материала стен (пусто у 10 635 строк, «кирпичный» 1754, «нет данных» 1496); - energy_efficiency: решение миграции 284 + реальный класс лишь у ~10% домов (у 25 595 из 41 790 значение «Не присвоен»); - elevators_count → passenger_elevators: в источнике это ОБЩЕЕ число лифтов, в houses раздельно пассажирские и грузовые → отдельная колонка; - playground/sportsground: в источнике id справочника (498/499/500), не флаг. Дубликаты houseguid реальны и взаимодополняющи: 912 guid'ов, 968 лишних строк, у одной строки пары заполнен area_total, у парной нет. Строки СЛИВАЮТСЯ по полям (первое непустое побеждает), иначе бэкфилл терял бы данные ~2% домов. estimator.py не тронут: аналоги подбираются FROM listings без JOIN к houses, встраивание признаков в подбор когорты — отдельная задача. Миграции 290 (staging frt_mkd + колонки houses) и 291 (сид расписания, enabled=false, interval_days 30). robots.txt источника требует Crawl-delay 10.	2026-09-09 00:33:09 +03:00
bot-backend	224f91e8fa	fix(cian): капча видна в отчёте прогона и банит узел на curl-пути (#3402) ... Два follow-up из ревью #3403. 1. Капча-волна была невидима в счётчиках. `_note_refusal` ключевался только по HTTP-статусу, а капча приходит с 200 (свой детект по <title>) или без статуса (сайдкар) → рос один `listings_failed_fetch`, `ban_kinds` оставался пустым, и волна отказа площадки читалась как дрейф нашей разметки. Теперь диагноз берётся сперва по ТИПУ исключения (`ban_kind_of_exception`), статус — фолбэк. Инвариант #3196 сохранён: 'unknown' по типу И None по статусу по-прежнему ничего не пишут. `ban_kind_of_exception` расширен с `AvitoBlockedError` до `ProxyBanError` — это ровно тот mixin, по которому generic-прокси-слой уже снимает узел с выдачи источнику. Для Авито поведение не меняется (AvitoBlockedError его наследует), Cian/DomClick перестают приезжать как 'unknown'. 2. curl-путь детектил капчу, но не банил: общий parse-путь лежит ЗА границей `with curl_proxy_url(...)`, и `CianBlockedError` поднимался уже после `mark_health(ok=True)` — узел, которому Циан показывает капчу, оставался в выдаче Циану (дефект #2700, только на HTTP 200). Проверка перенесена ВНУТРЬ блока, `finally` хелпера сам делает `mark_banned(source='cian')`. Тесты по значению (оба красные на main): батч с капчей → ban_kinds == {platform: 1}; curl-путь + HTML капчи → mark_banned == [(1, 'cian')], mark_health(ok=True) нет.	2026-09-06 15:30:12 +05:00
bot-backend	3fe2d310b2	Merge pull request 'fix(tradein/yandex): newbuilding resolve/fetch_jk через пул прокси + стоп на пустом пуле (#3197, точки 2-3)' (#3389) from fix/3197-yandex-newbuilding-proxy-pool into main	2026-09-06 02:24:44 +00:00
bot-backend	939a8a1646	fix(#3197): no_proxy_stop=1 как у соседей, INFO на финале хендлера, докстринг фабрики	2026-09-06 06:27:40 +05:00
bot-backend	cb5714fff0	fix(#3197): yandex newbuilding — обе точки в пул прокси + стоп на пустом пуле ... `YandexNewbuildingScraper.fetch_jk` и `resolve_yandex_jk_slug` строили `BrowserFetcher(source="yandex", endpoint=...)` без proxy_provider/use_pool/ environment — сайдкар брал env-узел SCRAPER_PROXY_URL, на проде выключенный (407 → camoufox InvalidIP → /fetch 503, факт #3386), то есть путь шёл мимо пула целиком, а прод-отказ «пул пуст» (#2616) был мёртв: он смотрит на environment, который до конструктора не доезжал. Обе точки собраны через build_browser_fetcher(config, "yandex", proxy_provider=...), как yandex/serp.py. Второе: общий `except Exception` в обеих функциях глотал NoProxyAvailableError и возвращал None — прогон, не ходивший к площадке, перебирал все ЖК и уходил в 'done'. Теперь «пул пуст» пробрасывается наружу (caused_by_no_proxy), sweep обрывается на первом доме с no_proxy_stop, а прогон финализируется как failed (образец дефекта — #3382, cian/detail.py).	2026-09-06 05:55:36 +05:00
bot-backend	caa3b8b056	fix(tradein): пустой пул ДО первого объявления теряет диагноз в записи прогона (#3384) ... Lease берётся один раз в BrowserFetcher.__aenter__, поэтому на проде с пустым пулом NoProxyAvailableError вылетает из самого `async with` — ДО первой карточки и мимо стоп-механики внутри цикла (no_proxy_stop = True; break), которая и пишет counters.no_proxy_stop. Общий `except Exception` ловил его и делал mark_failed с нулевыми counters без ключа: прогон, который к площадке не ходил вообще, в SQL-разборе простоя по counters.no_proxy_stop (#3288/#3367) не находится. Дыра одинаковая у всех трёх бэкфиллов (avito её тоже не обрабатывал: __aenter__ вызывается напрямую строкой 427, отказ уходит в тот же общий except). Правка — в трёх уже существующих обработчиках, которые и так зовут mark_failed: ключ no_proxy_stop=1 при caused_by_no_proxy(exc). Оборачивать `async with` в try/except пришлось бы с переносом ~200 строк тела под новый отступ в каждом файле, и покрывало бы только падение на входе; здесь ловится любой путь мимо цикла. Тест — через настоящий BrowserFetcher: подделан только провайдер прокси (его acquire поднимает NoProxyAvailableError), отказ рождается там же, где в проде. Проверяется failed + no_proxy_stop=1 + attempted=0 (у циана listings_processed=0) и ноль POST'ов в сайдкар. Closes #3384	2026-09-06 05:48:32 +05:00
bot-backend	8129e21b95	fix(tradein/cian): суточный бэкфилл истории — в прокси-пул, а не в env-прокси (#3197) ... BrowserFetcher(source="cian") в cian_history_backfill конструировался без proxy_provider/use_pool/environment — трёх аргументов, которые кладут "proxy" в тело POST /fetch. Сайдкар брал свой env-прокси (SCRAPER_PROXY_URL): пул из 4 узлов, его баны и ротация проходили мимо, а прод-отказ «пул пуст → не ходить на env/direct» (#2616) на этом пути был мёртв, потому что смотрит на environment. Проводка теперь как у соседей — domclick_detail_backfill и house_imv_backfill. Ожившему отказу нужен обработчик: NoProxyAvailableError ловился общим except на объявление, и батч крутил впустую весь список (пул пуст с первого — значит пуст и на 1000-м). Распознаём по цепочке причин, обрываем прогон, counters.no_proxy_stop=1 и mark_failed вместо mark_banned — отказ нашей стороны не должен записываться как бан Циана. Дома и оценки после стопа пропускаем: они идут через тот же пул. caused_by_no_proxy вынесен в scraper_kit.proxy_errors (у avito #3288 и domclick #3283 живут приватные копии — их схлопывание отдельной правкой).	2026-09-06 02:27:03 +05:00
bot-backend	7afaa12d75	Merge pull request 'fix(tradein/avito): брейкер добора считает долю только по отказам площадки — сайдкар/пустой пул не рвут прогон и не красят его banned' (#3367) from fix/3288-breaker-block-kind into main	2026-09-05 19:38:48 +00:00
bot-backend	78e3da6bc3	fix(tradein): маркер полноты — encryptedPhones ИЛИ redirectPhones (#3191) ... Ревью #3364. Требуя именно encryptedPhones, отбраковывали бы вечно необмеренный класс карточек «без телефона / только чат»: в очередь они возвращаются, а ключ не появится. redirectPhones измерен тем же замером #3192 и присутствует в обеих ветках (с куками и без). Текст ABORT: consecutive_none смешанный (фетч-ошибка + parse-None + недогруз) — «N подряд без обогащения», а не «недогруженных».	2026-09-06 00:14:43 +05:00
bot-backend	1a693192e1	fix(tradein): вид блока решает обрыв по доле и статус прогона (#3288 часть B) ... Прогон 5425 оборвался по доле блоков и получил статус banned на 48 «блоках», из которых 41 был отказом нашего сайдкара: record_block() вида не принимал, поэтому infra падал в числитель скользящего окна #3184 наравне с настоящим баном, а mark_backfill_finished считал диагноз только ради телеметрии. - record_block(kind): в числитель идёт только platform; всё остальное — в знаменатель (как record_failure), мимо серии и safety-net; - NoProxyAvailableError у avito — не блок и не отказ площадки: прогон завершается no_proxy_stop=1 + mark_failed «пул прокси пуст» (как домклик после #3283); опознаётся по цепочке __cause__, не по подстроке (#3272); - статус banned — только при доминировании platform; при infra прогон получает failed (нулевой результат) или done, с честной причиной.	2026-09-06 00:09:37 +05:00
bot-backend	4b5f8fb54c	fix(tradein): недогруженная карточка Яндекса — отказ, а не успех (#3191) ... Страница на 1,8 МБ без блока контактов приходит с HTTP 200 и валидным HTML: window.INITIAL_STATE на месте, parse отрабатывает — и частичная карточка уезжала в БД с detail_enriched_at, выбывая из очереди навсегда. Единственная проверка размера (newbuilding.py, len(html) < 500) отвечала на вопрос «пришло ли хоть что-то»: 1,8 МБ проходит её в 3600 раз. Признак полноты структурный + размерный, любой из двух даёт отказ: encryptedPhones (65 вхождений у полных карточек, 0 у недогруза; отдаётся и анонимной сессии — см. yandex_session.py) и settings.yandex_detail_min_html_bytes (1 МБ). Наблюдавшийся недогруз ловит именно структурный: 1,8 МБ порог проходит. В backfill проверка стоит ДО parse: исход incomplete ⊆ failed, save не вызывается, значит detail_enriched_at не проставляется и следующий снапшот (detail_enriched_at IS NULL) возьмёт объявление снова. Серия недогрузов двигает consecutive_none — тот же брейкер, что у parse→None, поэтому вечно недогружаемая карточка обрывает прогон, а не молотится (per-listing счётчика попыток в схеме нет). Фейковые ответы в тестах-соседях (#3196/#3338) теперь при HTTP 200 выглядят полной страницей — иначе они молча стали бы кейсами про полноту.	2026-09-05 23:59:15 +05:00
bot-backend	659543f004	fix(tradein/backfill): warning save-False называет оба id (avito) и не дублирует listing_id (yandex) ... Ревью #3347, два minor. 1. avito: WHERE в save_detail_enrichment ключуется по source_id из РАЗОБРАННОГО HTML (enrichment.item_id), а warning печатал row["id"] из снимка. При редиректе/подмене карточки строка с row-id жива, и читатель лога идёт искать несуществующую проблему не у той строки («текст ошибки называет гонца»). Печатаем оба: listing_id=%s item_id=%s. 2. yandex: listing_id стоял в строке дважды (в начале и как «id=%d» в хвосте) — убран дубль. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-05 23:06:22 +05:00
bot-backend	3658434c03	fix(tradein/backfill): save-False у yandex/avito больше не теряет попытку — attempted == сумма исходов ... Тот же дефект, что #3332 у domclick (#3335), у обоих соседей: `if save(...): enriched += 1` без else. UPDATE, не задевший строку (объявление удалено между снимком и записью), оставлял попытку без исхода — attempted переставал сходиться с суммой исходов, и расхождение читается как потерянный отказ площадки. Разбор ВСЕХ точек выхода из цикла попыток показал, что у соседей это единственная дыра: обрыва «пул прокси пуст» у них нет (resolve_proxy_url бросает ProxyPoolExhaustedError ДО цикла), а budget/SIGTERM-брейки стоят до `attempted += 1`. Исход — failed с отдельным warning про ненайденную строку. Формы тождества разные и это не описка: у yandex blocked ⊆ failed (#3196), у avito blocked/gone/failed — непересекающиеся корзины. Тесты — по значению (числа, не «не бросило»), плюс контроль на противоположную ошибку (исход не начисляется дважды). В test_3332 добавлен запрошенный ревью кейс: транспортный сбой → пустой пул даёт attempted=2 failed=2, а не 3. Closes #3338	2026-09-05 22:47:08 +05:00
bot-backend	126608e1fc	Merge pull request 'fix(tradein/domclick): обрыв «пул пуст» и save-False больше не теряют попытку — attempted == сумма исходов' (#3335) from fix/3332-domclick-counter-identity into main	2026-09-05 17:36:54 +00:00
bot-backend	76b24e9f4d	fix(mera-public): подписи метрик снижения цены и бенчмарк отчёта не называют площадку ... Замечание юриста (Сайт_МЕРА_v2, п.3): публичный измеримый контент не должен строиться на названных данных площадок. - landing_stats.py: note метрик price_cut_share_pct / price_cut_median_pct_per_month «Только Домклик (…)» → «Только одна из площадок (…)». Текст персистится в landing_stats.note и рендерится на лендинге в блоке «цена ошибки» — после деплоя нужен пересчёт (refresh_landing_stats), деплой кода note не перепишет. - HeroSummary.tsx / IMVBenchmark.tsx: убраны видимые «IMV» и title «Information Market Value» / «Индекс Market Value» — бренд-термин оценочной модели площадки; подпись — «оценочная модель» + sourcePublicLabel. - public-copy-no-platform-names.test.ts: «IMV», «Information Market Value» добавлены в BANNED (гейт 34/34).	2026-09-04 11:27:32 +03:00
bot-backend	5541aa9d37	fix(mera-public): публичная копия — сервис не называет себя оценщиком, площадки-источники не названы ... Три юр-правки по документу владельца продукта «Сайт_МЕРА_v2» (31.08.2026), сделаны локально 31.08, но не были закоммичены — на meraocenka.ru всё оставалось по-старому. 1. «Оценщик» про собственный алгоритм. Витрина сделок (`landing_showcase_deals.py`, REJECTION_RULE/NOTE) и сноска статьи «Как оценить квартиру» теперь говорят «расчёт МЕРЫ»: самоназвание обесценивало дисклеймер «не официальный отчёт оценщика». Комментарии и докстринги не тронуты — посетитель их не видит. 2. «Путь 2»: «стоимость услуг фиксированная и известна заранее» — читалось как фиксированная цена квартиры. 3. Названия площадок убраны из видимой копии лендинга и веб-отчёта. Канон — `publicLabel` + `sourcePublicLabel()` в `source-registry.ts`: одна площадка = один номер «Источник N» и один цвет точки (цвет остаётся опознавателем между блоками), Росреестр под своим именем, неизвестный id → «Другой источник» (раньше fallback отдавал сырой id). Три параллельные реализации `sourceLabel` сведены к одной; `sourceLabel()` с реальными именами живёт для админки. Backend: якорь confidence_explanation «по оценке Avito IMV» → «по оценочной модели площадки». Подсказки геокодера «Yandex / Nominatim» и «по Яндексу» сняты из клиентских форм. Гейт `public-copy-no-platform-names.test.ts` сканирует mera-public/** и components/trade-in/** без комментариев, по Unicode-границе слова; список запретов регистрозависимый намеренно (строчные id `"avito"` законны), поэтому капс-варианты и словоформы перечислены явно — «6202 ОБЪЯВЛЕНИЯ ДОМКЛИК» в статье именно так проходил первую версию гейта. Не закрыто здесь: клиентский PDF (#3341) и ссылки на объявления на доменах площадок. Текст витрины хранится в БД (`landing_showcase_runs.rejection_rule`, `landing_showcase_deals.note`), планировщика у пересчёта нет — после деплоя нужен ручной пересчёт или UPDATE трёх подстрок на проде.	2026-09-03 09:50:41 +03:00
bot-backend	e2e7e17f95	fix(domclick): каждая попытка добора получает исход (#3332) ... Обрыв «пул прокси пуст» уходил из цикла между attempted++ и записью исхода, поэтому тождество attempted = enriched + failed + blocked ломалось ровно на 1 (прод: 5 прогонов с diff=1). Исход честно failed, не blocked: к площадке не ходили, отказала наша инфраструктура — тот же разряд, что у транспортных сбоев (#3283); причина прогона по-прежнему в no_proxy_stop=1 + mark_failed. Та же дыра закрыта у save_detail_enrichment(...) is False: карточка разобрана, но строки уже нет — попытка была, исхода не было. Closes #3332	2026-09-02 17:35:48 +05:00
lekss361	add974db65	feat(tradein/avito): бан площадки не менял IP — прогон добивался в тот же забаненный адрес (#3283) (#3313)	2026-09-01 08:05:48 +00:00
lekss361	9219ab6507	feat(tradein/avito): ротация exit-IP по счётчику попыток в доборе карточек (#3302)	2026-08-31 12:09:03 +00:00
bot-backend	e45b05845e	fix(mera-landing): наличие схемы улицы входит в полноту строки витрины ... Первой строкой витрины и первым раундом игры «Проверьте себя» стояла единственная из двадцати сделка БЕЗ улицы: у неё вместо схемы улиц рисовался полигон района. Причина — `completeness()` считала район, этаж и этажность, но не улицу, хотя именно она решает, будет ли у строки карта. Схема улицы — такое же ВИДИМОЕ поле, как район: строка, которой нечем нарисовать карту, полнее строки с картой быть не может. Признак берётся из уже загружаемого индекса улиц (`StreetIndex.lookup`, поиск в памяти); индекс поднят выше отбора, дорогие пространственные запросы остались в `_schemes_for` и по-прежнему считаются только для показанных строк. Отбор по ВЕЛИЧИНЕ ОШИБКИ не введён и введён быть не может: строка с отклонением +75,7% остаётся в витрине, просто больше не открывает её. Прежнее правило «наличие схемы на отбор не влияет» в докстринге `_schemes_for` заменено с разбором, почему оно давало этот дефект. Тест двусторонний: при прочих равных строка со схемой выше строки без неё, а строка без улицы остаётся в витрине. Фальсифицирован — снятие `row.has_street` из `completeness` даёт красное ПО ЗНАЧЕНИЮ ([9, 8] вместо [8, 9]), не по исключению. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-31 11:22:39 +05:00
bot-backend	1e02badbe9	fix(tradein/domclick): бан сайдкара наследуется от httpx-ошибки и уезжал в транспортные сбои (#3283) ... Правка #3286 разделила отказы площадки и сбои нашей стороны по природе исключения: httpx-ошибка в цепочке причин = транспорт. Прод показал дыру на первом же прогоне (5406): СБОЙ #1/400 (подряд=1/10, http=401, kind=platform, не блок площадки): DomClick detail: sidecar detected platform refusal Заголовок «не блок площадки» стоит над записью, где kind=platform и код 401, то есть над самым что ни на есть отказом площадки. Причина в иерархии: SidecarBanPageError объявлен как подкласс httpx.HTTPStatusError, поэтому проверка на httpx, стоявшая первой, забирала генуинный бан себе. Порядок проверок перевёрнут: бан сайдкара отсекается ДО общей httpx-ветки. Остальное поведение #3286 не тронуто — обычная 500 от сайдкара по-прежнему транспортный сбой. Тесты: +4, включая закрепление самой предпосылки (issubclass проверяется явно, чтобы смена иерархии не отключила проверку молча) и страховку, что обычная 500 осталась сбоем. Проверено мутацией: снятие порядка роняет тест и печатает самопротиворечивый лог «10 сбоев подряд без единого отказа площадки, диагнозы: {'platform': 10}». Набор целиком — 5210 passed.	2026-08-30 17:02:46 +03:00
bot-backend	42913d2843	fix(tradein/domclick): таймаут сайдкара и пустой пул считались отказами площадки (#3283) ... Прогон 5399 умер по правилу «3 блока подряд», не обогатив ни одной карточки из 400. Отказом Домклика не был ни один из трёх: два — HTTP 500 от сайдкара (таймаут навигации), третий — пустой пул, при котором запрос к площадке не отправлялся вовсе. Лог абортa сам это печатал: диагнозы {'unknown': 3}. Различать по HTTP-статусу нельзя: настоящий QRATOR-челлендж приходит без статуса и неотличим от таймаута — на этом и стояли прежние тесты. Различима природа исключения, причём разделение уже проведено в fetch_detail: генуинный бан приезжает через SidecarBanPageError или маркеры в parse_detail_html, а транспорт — через с , то есть с httpx-ошибкой в цепочке причин. Три правки: * пустой пул (NoProxyAvailableError в цепочке) — не блок, а остановка прогона: продолжать бессмысленно, каждая следующая карточка упрётся в то же. Прогон уходит в failed, а не banned — запись не должна утверждать про площадку то, чего не было; * транспортные сбои идут в failed, туда же, куда давно идёт DomClickParseError («schema drift, not a block»), и счётчик блоков не трогают; * отдельный сторож на молчаливый отказ: max_consecutive_soft_failures=10, иначе снятие хайртриггера оставило бы прогон без тормоза вовсе. Тесты: 10 проверок, включая дословный сценарий 5399 и страховку «генуинные блоки по-прежнему рвут прогон после трёх». Проверено мутациями: возврат пустого пула в блоки роняет 2, возврат транспорта — 6, снятие сторожа — 2. Четыре существовавших теста на генуинный блок продолжают проходить без правки — это и показывает, что разделение проведено по верному признаку. Набор целиком — 5206 passed, 37 skipped.	2026-08-30 16:33:56 +03:00
bot-backend	5f9dc5d512	feat(tradein/cian): у Циана не было добора карточек — только побочный эффект задачи про историю (#3284) ... Карточки Циана доставались побочным эффектом cian_history_backfill, а её выборка ключуется по offer_price_history. Следствия на 30.08: карточка есть у 4494 из 25222 объявлений (17.8% — последнее место при втором месте по объёму), 19046 без истории при квоте 100/сутки (190 дней на остаток, тогда как очередь растёт вдвадцатеро быстрее), и 1697 объявлений с историей и без карточки, которые исторической выборке недостижимы в принципе. Фетчер при этом исправен: прогоны 5154/5240/5328 дали 100/100, 99/100, 100/100. Чинить нечего — не выдана мощность. Добавлен второй режим выборки (listings_pending="detail", по detail_enriched_at, свежие первыми) и второе расписание поверх ТОГО ЖЕ тела: машинерия работает, дублировать её новым модулем незачем. Историческая выборка оставлена побайтово — по ней живёт суточный прогон. batch_size=400 не на глаз: замеренный темп ~28с на объявление, порог reap_zombies 6ч по heartbeat, бюджетного сторожа у задачи нет — 400×28с≈3.1ч проходит, 800 как у Яндекса (≈6.2ч) убивало бы жнецом. Расписание засеяно enabled=false, как domclick_detail_backfill в миграции 175: это третий круглосуточный добор на общий пул из четырёх узлов, влияние на соседей надо посмотреть, а не предположить. Тесты: 13 проверок, ключ выборки / порядок / неизменность прежнего режима / проводка параметров через посредника / регистрация обоих source. Проверено мутациями: снятие ORDER BY, молчаливый дефолт вместо ValueError и потеря listings_pending в посреднике роняют по 2-3 теста каждая. Набор целиком — 5196 passed, 37 skipped.	2026-08-30 15:34:36 +03:00
bot-backend	58e18e6fec	fix(tradein/avito): браузерный путь ходил на каждую карточку холодным (#3251) ... Пройденный QRATOR proof-of-work выбрасывался после каждой карточки: `reuse_context` во всём репозитории передавал ЕДИНСТВЕННЫЙ вызов — domclick_detail_backfill.py:346. Значит каждый /fetch Авито шёл через sidecar'овский browser.new_page(), то есть новый изолированный context с пустой банкой кук. В логе прод-сайдкара это видно прямо: «PoW-челлендж снят за ~1000мс» печатается на КАЖДОЙ успешной карточке — челлендж решается заново каждый раз, а не один раз на прогон. Эффект той же правки у Домклика измерен и записан в domclick_detail_backfill.py:331 — 26 последовательных фетчей сайдкара дали 100% блоков, те же карточки в тёплом контексте 5/5 за ~2с. Второй холод — сам заход: providers/avito/detail.py звал fetch(full_url) голым, без origin и без Referer, тогда как Домклик (#3247) идёт fetch(card_url, origin=SERP, referer=origin). Существующий для Авито прогрев (warm_up_session) живёт только в curl-пути и с 22.08 в проде мёртв — AVITO_DETAIL_BACKFILL_USE_CURL выставлен в false. Что сделано: - avito_detail_backfill: reuse_context=True + request_context_reset() РОВНО один раз за прогон и только на AvitoBlockedError. Не на AvitoSidecarUnavailableError (подтип AvitoRateLimitedError — отказ нашего тракта, не бан площадки) и не на AvitoListingGoneError. Зеркалит #3212: сброс на каждый блок сам себя поддерживает — пропуск живёт в context'е, сброс его выбрасывает, повторная проверка с того же IP снова блокируется, одна осечка даёт каскад. - fetch_detail: необязательные origin/browser_referer (имя referer уже занято под Referer curl-пути, это разные фетчеры и разные поля). Дефолт None → payload и поведение city_sweep/pipeline/admin не меняются. - _serp_origin_for: городская SERP из URL карточки, хост берётся из самого url. Попутно — дефект якорной вкладки сайдкара, найденный при переносе. _ensure_anchor_page отдавала True на ЛЮБУЮ живую вкладку, не сверяя её с запрошенным origin. А origin у обоих caller'ов выводится ИЗ URL карточки и меняется вместе с городом (Авито — сегмент пути, Домклик — поддомен). После первой же карточки другого города Referer называл выдачу, которую этот контекст никогда не открывал: ни куки её, ни тайминга, площадка видит заявленный переход без единого следа. Ровно то, что #3258 запретил делать фолбэкам якорного поиска. Добавлен _anchor_origins: origin сменился — вкладка переоткрывается. Чинит и Домклик тоже. Заход через поиск Яндекса (BROWSER_ANCHOR_VIA_SEARCH) для Авито НЕ включается — расширять этот список без отдельного замера запрещает комментарий у самой константы. Хранилище авторизованных сессий Авито (#3179/#3180) этой правкой не заменяется. База для сравнения снята ДО выката и записана в #3251: доля блоков от попыток 46.9% / 74.2% / 96.4% / 69.8% / 52.9% / 62.3% по суткам 25-30.08. Сравнивать после деплоя по доле блоков и обогащению за сутки, а НЕ по статусу прогона: ratio-критерий обрывает КАЖДЫЙ прогон, и статус banned про площадку ничего не говорит. Тесты: backend 5150 passed / 37 skipped, сайдкар 211 passed (было 206 + 5 новых на переезд якоря), ruff чист. Refs #3251, #3180, #3118, #3212, #3247, #3258	2026-08-30 11:47:15 +03:00
bot-backend	c467584de3	fix(mera/landing): «Цена ДКП» — цена договора, а не произведение; экспозиция считает и Домклик ... Витрина показывала fact_rub = price_per_m2 * area_m2, хотя deals.price_rub лежит в той же строке и не использовалась. price_per_m2 в базе integer, поэтому под подписью «Цена ДКП» ехала реконструкция: 4 799 995 вместо 4 800 000, 3 649 995 вместо 3 650 000 (прод, сделки 5777343 и др.). Теперь price_rub едет из выборки (DealSample.price_rub) и показывается как есть; err_pct считается от той же величины. Строка без price_rub НЕ показывается — подставлять реконструкцию в одну строку из двадцати значило бы спрятать тот же дефект (на проде price_rub заполнен у 33 555 из 33 555 сделок выборки витрины). Вторая находка аудита (listing_date якобы «когда увидели МЫ», экспозиция занижена втрое) НЕ ПОДТВЕРДИЛАСЬ. listing_date пишут cian (added_ts), yandex (creationDate) и avito (дата карточки выдачи) — это дата публикации у источника. Там, где заполнены и listing_date, и publish_date, они совпадают: yandex 10 761 из 10 903, avito 474 из 569, медиана разницы 0 дней. 75 дней у аудитора — эффект другой ВЫБОРКИ: publish_date есть у 15 058 активных строк (yandex + Домклик, оба старые), listing_date — у 25 982 (плюс cian с медианой 17 дней и 87% avito с медианой 19). Настоящий дефект рядом: по одному listing_date Домклик выпадал целиком (0 из 3061 активной строки), метрика считалась по 83.6% активных объявлений, и подпись об этом молчала. COALESCE(listing_date, publish_date) → охват 95.2% (29 568 из 31 068), медиана та же — 26 дней; охват теперь назван в note. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 00:10:36 +05:00
bot-backend	2390eec740	fix(mera/b2c): вернуть координаты сделки, снесённые моим же коммитом про студию ... Коммит 555cce44 обещал в сообщении одно — подписать студию вместо «0-к», — а сделал ещё и другое: удалил миграцию 280_landing_showcase_deals_coords.sql и откатил правки mera.py, landing_showcase_deals.py и двух тестов из коммита cd2a7671. Заметил не я: об этом написал агент, которому потом достался номер 281 и который увидел дыру на 280. ПРИЧИНА. `git commit` фиксирует ИНДЕКС ЦЕЛИКОМ, а не то, что было добавлено последним `git add`. В индексе главного рабочего дерева лежали staged-удаления, оставшиеся от параллельных агентов (они работают в своих worktree, но индекс основного дерева переживает переключения веток). Я добавил два файла, а закоммитил вместе с ними чужие удаления. Что восстановлено: миграция 280 целиком, поля lat/lon в ShowcaseDeal, перенос координат в пересчёте витрины, оба теста. Обе величины нужны и не заменяют друг друга: схема улицы (281) закрывает 92% сделок, координата (280) — карту района для остальных 8%. Конфликты сведены вручную: механическое «оставить обе стороны» задвоило список колонок в INSERT и в SELECT, что тесты бы пропустили, а прод — нет. Проверено: 5085 passed, 35 skipped; миграции 275-281 без дыры; список колонок INSERT сверен со списком значений программно (15 и 15, порядок совпадает).	2026-08-29 23:25:44 +05:00
bot-backend	ca3f073b0e	feat(mera/b2c): улица сделки доезжает до витрины готовой схемой, а не геометрией ... Карта в карточке игры показывала полигон района — единственную геометрию, до которой у tradein был доступ. Улицы живут в базе gendesign, foreign table и гранта на них не было. Мост по образцу соседей (v_tradein_cad_buildings / v_tradein_osm_poi_ekb): gendesign 195 — вьюха v_tradein_osm_roads_ekb (highway + water) с GRANT В ТОМ ЖЕ ФАЙЛЕ (после #3227 грант отдельной миграцией теряется при пересоздании); tradein 281 — foreign table gendesign_osm_roads_ekb плюс колонки street_name / street_scheme в landing_showcase_deals. Пересчёт витрины кладёт в строку УЖЕ СПРОЕЦИРОВАННЫЕ SVG-пути окна 840x840 м вокруг центра улицы. Проекция — та же равнопромежуточная с cos(широты), что в export_ekb_districts_svg.py; второй в проекте нет. Замер 2026-08-29: GeoJSON того же окна 7-8 КБ на строку, схема — 2.8-2.9 КБ. ЧТО ДАННЫЕ ВЫДЕРЖИВАЮТ, И НИ СЛОВОМ БОЛЬШЕ · Это УЛИЦА, а не дом: deals.address уровня улицы, номер дома у 2.7% сделок. В схеме намеренно НЕТ координат окна и констант проекции — точку дома по ней нельзя поставить даже случайно. Это замок, а не забывчивость. · Зданий нет: cad_buildings — 18 307 контуров на город, в плотном центре 51 здание на радиус 450 м, где их в разы больше. Нарисованная застройка заявляла бы полноту, которой в данных нет. · Улицы — фильтрованная выгрузка «источников шума»: именованные покрыты хорошо, дворовые и служебные проезды отсутствуют. · Улица сматчилась у 550 названий из 654 — 31 410 сделок из 34 021 (92.3%). Остальным street_scheme = NULL, и это штатно: фронт показывает район, который для этого и оставлен. · Перекрёсток («Челюскинцев/Шейнкмана») берём первой улицей: таких адресов три на 34 021 сделку, и обе улицы одинаково верны на уровне улицы. · Наличие схемы НА ОТБОР СТРОК НЕ ВЛИЯЕТ — то же правило, что запрещает отбор по величине ошибки: иначе витрина показывала бы не работу оценщика, а те 92% адресов, что удобно легли на OSM. Тесты (каждый сломан вручную и покраснел): нормализация на реальных адресах включая ё/е и «8 Марта»; недоступная вьюха и упавший запрос дают None, а не исключение; схема не раздувается — потолок в байтах на реальной плотности плюс прямая проверка округления до 0.1.	2026-08-29 23:25:44 +05:00
bot-backend	4e3279d448	fix(mera/b2c): студия подписывалась как «0-к» на витрине сделок ... Увидел на скриншоте карточки игры: «0-к, 25,9 м²». Замер на проде — 3 строки витрины из 20 имеют rooms = 0, то есть каждая шестая карточка так и выглядит. «0-к» читается как ошибка выгрузки, а не как тип квартиры. Студией её называет и наш собственный бэктест (per_rooms.label в scripts/backtest_estimator.py), и рынок. Тест двусторонний и фальсифицирован: возврат «0-к» для rooms=0 красит его по значению, обратная правка — снова зелено.	2026-08-29 23:25:44 +05:00
bot-backend	f3401badd0	feat(mera/b2c): координата сделки доезжает до витрины — с записанной границей честности ... Карта лэндинга не может показать точку, пока её нет в витрине: район, комнаты, площадь и квартал в `landing_showcase_deals` есть, координаты не было. Что сделано: миграция 280 добавляет lat/lon (double precision, NULLABLE), задача пересчёта переносит их из `deals`, ручка /showcase отдаёт их как Optional[float]. ГРАНИЦА ЧЕСТНОСТИ, записанная в трёх местах (COMMENT колонок, `note` каждой строки, докстринг задачи), а не только в голове автора: это ЦЕНТРОИД УЛИЦЫ, а не дом. Замер на проде 2026-08-29 по той самой выборке, из которой набирается витрина (deals, city='Екатеринбург', deal_date >= '2025-01-01'): 34 021 сделка, 34 017 с координатой, но РАЗЛИЧНЫХ точек всего 991 — ≈34 сделки в одной точке, при 2.7% известных номеров дома. Точка верна на масштабе района и улицы и неверна на масштабе дома; `note` едет на фронт вместе с числами, поэтому следующий, кто возьмётся зумить карту, об этом споткнётся. NULLABLE и без отбраковки: строка без координаты остаётся на витрине с lat=lon=None. Выбрасывать сделку за отсутствие точки — отбор по признаку, не связанному с качеством оценки, то есть та же порча витрины, которую здесь уже чинили (порог по величине ошибки). Тесты двусторонние, каждый проверен фальсификацией — краснеет по ЗНАЧЕНИЮ: * перестановка lat/lon в build_row → 60.6055 == 56.8386 * `if lat is None: return None` → None is not None * перестановка lat/lon в ручке → 60.6055 == 56.8386 * фильтр строк без координат в ручке → len([]) == 1 Перестановку широты и долготы не ловит ни схема, ни тип (обе float), поэтому в фикстурах намеренно непохожие величины: 56.8386 против 60.6055. Фронтенд не тронут — его делает следующий шаг. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 23:25:44 +05:00
bot-backend	abe559cf8f	fix(mera): витрина больше не отсеивает промахи оценщика, счётчики едут на фронт ... Ревью MAJOR по честности, два пункта. 1. Убран MAX_ABS_ERR_PCT = 40 из build_row. Докстринг модуля сам запрещает отбор по величине ошибки, но запрет был реализован только в _sort_key, а фильтр — тот же отбор ступенькой раньше, и злее: строка не попадала даже в кандидаты. Обоснование «отклонение >40% — почти всегда занижение ДКП ради налога» не держится: _load_sample уже режет выборку санитарным диапазоном ₽/м² (для ЕКБ это глобальные PPM2_MIN=30k / PPM2_MAX=600k — город намеренно не заведён в deal_city_price_bands), то есть грубые занижения вырезаны выше по потоку и ПО СВОЙСТВУ САМОЙ СДЕЛКИ. Всё, что после этого дало большую ошибку, — работа оценщика, и посетитель обязан её видеть. Честность про заниженные ДКП перенесена в note каждой строки. Заодно убраны MIN_FACT_PPM2=30k (дублировал уже применённый фильтр) и MAX_FACT_PPM2=1.2M (недостижим при потолке выборки 600k): из трёх отбраковок в проде срабатывала ровно одна — та, что льстила витрине, а два мёртвых порога читались как работающие. Осталась только структурная отбраковка «нет прогноза / квартала / площади». 2. Счётчики прогона выведены в ответ ручки. Итог пересчёта пишется в landing_showcase_runs (миграция 277) и уезжает в ShowcaseResponse.stats вместе с правилом отбраковки: показано 20 из N годных, рассмотрено M сделок. Отдельная таблица, а не колонки в строках, — иначе в самом важном случае (показывать нечего) счётчики исчезли бы вместе со строками. Ручка теперь берёт и строки, и числа ИЗ ОДНОГО прогона: иначе пустой прогон показал бы вчерашние строки под сегодняшними счётчиками. Тесты двусторонние и проверены на сломанном коде: возврат любого порога по ошибке → красный с величиной отклонения в сообщении; возврат любой границы ₽/м² → красная своя половина; stats=None при живом прогоне → красный.	2026-08-29 19:20:04 +05:00
bot-backend	b72dbc5da3	feat(mera): витрина лэндинга на реальных ДКП-сделках вместо выдуманных ... Лента «МЕРА сказала X — продали за Y» жила на константах в marketing-v3.ts. Здесь появляется её настоящий источник: сделки Росреестра по ЕКБ, прогнанные через тот же спайн оценщика, что и боевой расчёт (backtest_estimator). Отбор строк идёт по полноте данных и свежести квартала и НЕ смотрит на величину ошибки: отбор по малой ошибке дал бы формально работающий код и врущую витрину — показанные строки перестали бы быть выборкой из работы оценщика. Свойство закреплено двусторонним тестом. Витрина не показывает адреса (номер дома есть у 2.7% сделок) и не показывает дня сделки (deal_date — первое число квартала). Каждая строка несёт note о том, что замер не point-in-time. Заниженные ради налога ДКП отбрасываются по |отклонению| > 40% и ₽/м² вне [30k; 1.2M], счётчик отброшенного — в лог.	2026-08-29 19:20:04 +05:00
bot-backend	e9a2fff0b3	test(mera/b2c): гейт на сам SQL доли снижений + чистка протухших метрик ... Ревью: гейт охранял не то место. Подмена знаменателя красила три теста, но дефект «84.8% вместо 48.1%» живёт в SQL — во включении однострочных записей истории (у domklik одна запись = «цену не менял») в знаменатель. Ревьюер вернул дефект условием n_rows >= 2 в CTE moved, и все 25 тестов остались зелёными: текстовые пины держали только span_days и max_abs_pct. Новый пин держит обе половины: однострочные попадают в moved веткой CASE со значением 0, и нигде в запросе нет фильтра по числу записей истории (ни в WHERE, ни HAVING). Живой прогон на подготовленных строках не заведён намеренно: DATABASE_URL в тестовой джобе — заглушка, Postgres там нет, и тест по образцу test_purge_expired_trade_in_data.py молча скипался бы, то есть не гейтил бы ничего. Фальсифицировано руками — с n_rows >= 2 тест красный и называет причину. Второе: метрика, у которой пропал вход, больше не доживает в таблице со старым computed_at (ручка отдавала её неотличимо от свежей). Строки вне сегодняшнего набора удаляются в той же транзакции. На ПУСТОМ наборе чистка не ходит: разом отвалившиеся все входы — признак поломки прогона, а не пяти одновременных «данных больше нет». Оба поведения покрыты тестами, оба проверены на сломанном коде.	2026-08-29 19:10:04 +05:00
bot-backend	b5645ec1bc	feat(mera/b2c): витринные метрики лэндинга считаются по проду ... Числа на публичном лэндинге лежали литералами во фронте (mera-public/marketing-v3.ts) — то есть были выдуманы и не имели срока годности. Теперь их считает ночная задача и отдаёт публичная ручка, вместе с размером выборки и описанием того, что именно измерено. Что считается: число расчётов и период работы, медиана аналогов на расчёт, медианная ЭКСПОЗИЦИЯ активного объявления по ЕКБ (не срок продажи — так и написано в note), доля снижавших цену и медианное снижение за 30 дней, сделки Росреестра по ЕКБ за 12 месяцев. Ценовые метрики берут ТОЛЬКО domklik: у avito/yandex триггер не пишет стартовую цену, а yandex вдобавок сеет синтетическую пару со сдвигом в сутки — на такой смеси «снизил» и «не снижал» неразличимы. Знаменатель доли — все объявления, наблюдавшиеся от 14 дней, включая не менявшие цену; считая только по менявшим, получили бы 85% вместо честных 48%. Метрика без входных данных строку НЕ пишет: подставленный ноль читался бы как измеренный ноль. Пустая таблица — валидные {} и 200, а не 500. «Точность прогноза» и «срок продажи» здесь не считаются намеренно — таких величин в данных нет.	2026-08-29 18:45:26 +05:00
bot-backend	fd95c962bb	fix(tradein/domclick): backfill ходил в сайдкар мимо прокси-пула (#3197 ч.1) ... BrowserFetcher(source="domclick", reuse_context=True) конструировался без proxy_provider/use_pool/environment -- тела POST /fetch не несли "proxy", сайдкар брал свой env-прокси, и прогон шёл мимо пула целиком: ни выбора узла по affinity, ни scrape_proxy_source_bans, ни ротации при блоке. Тот же дефект уже чинили на avito_detail_backfill/house_imv_backfill (#2698) -- этот call site оставался последним непочиненным. environment обязателен: без него отказ «пул пуст» на этом пути мёртв (#2616 шаг 1). reuse_context=True сохранён без изменений. Заодно поправлен устаревший комментарий над конструктором: ссылался на scrape_proxies.provider_affinity='domclick' и миграцию 173 -- на проде такого больше нет (миграция 253 сняла резервацию узла, #2800), все четыре включённых узла (id 1/9/10/11) имеют provider_affinity='any'. test_3118_domclick_warm_context.py обновлён под новую сигнатуру вызова (assert_called_once_with -> точечная проверка нужных kwargs).	2026-08-29 15:26:14 +03:00
bot-backend	09bdd7888b	fix(tradein/domclick): перезапуск браузера на карточку уничтожал пропуск QRATOR (#3212) ... ДомКлик закрыт QRATOR с proof-of-work: первый запрос отдаёт 401 и заглушку с задачей, браузер её решает, дёргает /__qrator/validate и получает пропуск в куках (qrator_jsid2 + qrator_jsr). Пропуск живёт в cookie jar, то есть в browser context'е — а прод брал каждую карточку в новом контексте, выбрасывая его. Повторная валидация с того же IP получала 403 и страницу bot-mitigation. Замер (прод, прод-прокси, по 6 карточек): общий контекст, одна вкладка 6/6, validate не вызывался ни разу общий контекст, вкладка на карточку 6/6, validate не вызывался ни разу новый контекст на карточку (= прод) 1/6, validate = [304, 403] на каждой боевой путь /fetch с reuse_context 6/6 при 0 перезапусков и 1 контексте Что правится: * снят код-дефолт domclick=1 из #3205: перезапуск процесса гарантированно уничтожает контекст, то есть лечил симптом, который сам же и создавал. Ручка per-provider и domclick как отдельный провайдер остаются; * сброс контекста в бэкфилле был на КАЖДЫЙ блок — стал один раз за прогон. Это и объясняет провал #3193: сброс выбрасывал пропуск, следующий фетч блокировался гарантированно, что снова вызывало сброс. Приёмка тогда дала ровно 1 успех из 10; * снята неверная формулировка «отказ, а не челлендж» из #3204/#3205 — 26 624 байта это РЕЗУЛЬТАТ проваленного PoW, а не статика вместо него. Ошибка вышла из метода: HTML читали на 4.5-й секунде и не смотрели в сеть. Замер 6/6, которым обосновывали #3205, был испорчен: в логах сайдкара после каждой страницы стоит «recycle threshold (1) достигнут, перезапуск браузера». Тесты: два кодировали domclick=1 — переписаны через подставной словарь, чтобы уровень «код-дефолт поставщика» продолжал проверяться, а не исчез вместе с записью. Тест сброса требует ровно одну попытку за прогон. 159 passed (сайдкар), 4972 passed / 37 skipped (backend).	2026-08-29 14:09:23 +03:00