1120 commits

Author	SHA1	Message	Date
bot-backend	1bf9c4b632	test(tradein): гонка на sleep(0.05) вешала тест потолка оценок на 120с (#3270) ... Тест занимал все слоты семафора четырьмя висящими запросами и ждал, что они дошли до acquire, обычным сном на 50 мс. На нагруженном раннере этого не хватало: пятый запрос заставал свободный слот, входил в подменённую оценку и вставал на gate.wait() — а gate.set() стоит ниже по тому же корутину. Дедлок до pytest-timeout, две минуты простоя job'а и красный CI на постороннем PR (#3268). Сон заменён счётным барьером: подменённая оценка отпускает семафор при входе, тест дожидается ровно _CONCURRENCY входов. Вход означает, что слот уже захвачен, — это то самое условие, которое сон угадывал по времени. Проверено пробой с намеренно свободным слотом (держателей на одного меньше): старая структура висит до таймаута, новая падает за 12с с понятным сообщением.	2026-08-30 12:02:45 +03:00
lekss361	169121cea8	Merge pull request 'fix(tradein/avito): браузерный путь ходил на каждую карточку холодным (#3251)' (#3267) from fix/3180-avito-warm-context into main	2026-08-30 08:55:33 +00:00
bot-backend	aec05280fa	fix(tradein/domclick): «система защиты от протечек» в объявлении читалась как блок QRATOR ... _extract_json искал маркеры блока подстрокой по ВСЕМУ телу ответа — до разбора JSON, то есть и по пользовательским описаниям объявлений. Прод 30.08, прогон 5363: продавец написал в описании квартиры «🔹 Система защиты от протечек». Подстрока совпала с маркером «система защиты», ответ на 107 183 байта с двадцатью валидными офферами был объявлен блок- страницей, свип оборвал все комнатные корзины и забанил живой узел пула на 6 часов. Совпасть так же могут «captcha» и «qrator» — в тексте объявления, в имени агентства, в ссылке. Порядок перевёрнут: сначала разбор JSON, маркеры — только если разбор не удался. Разобранный JSON нужной формы блок-страницей быть не может, QRATOR отдаёт HTML, так что валидный разбор сам по себе доказывает отсутствие блока. Тот же порядок давно применён в detail.py — там маркеры смотрят только когда __SSR_STATE__ не найден; свип был единственным местом с обратной логикой. Мусор без маркеров теперь ValueError, а не блок: за неразобранный ответ неизвестной природы узел банить нельзя. Тест проверен мутацией: со старым порядком 8 проверок из 11 краснеют, включая дословный фрагмент описания из прогона 5363.	2026-08-30 11:49:47 +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	5baf07d6e6	fix(tradein/domclick): свип брал BFF навигацией браузера — теперь подзапросом (#3264) ... BFF-ручка Домклика не страница, а JSON-эндпоинт SPA. Сайдкар умел ровно одно — page.goto(url), — и навигацией браузера на API-хост мы делали то, чего настоящий клиент не делает никогда. Перехват сети на живой выдаче 30.08 это и показал: офферы приезжают в SSR-документе, а к BFF ходят XHR'ы за гео, районами и метро. Через мобильные узлы пула такая навигация упиралась в ChallengeTimeout: прогоны 5330 и 5351 — 9 из 9 и 6 из 6 запросов зависли на челлендже, 0 лотов. Карточки через те же узлы в те же минуты шли. Замер трёх режимов на одном узле, один и тот же ресурс: BFF navigate ChallengeTimeout, 55с BFF subresource HTTP 200, 52 байта, 6с BFF page_fetch ошибка Подзапрос проверен вширь: все шесть комнатных корзин HTTP 200, суммарно 6359 офферов против 6367, снятых напрямую с резидентного IP (расхождение — дрейф фонда за пару часов); список офферов отдаётся на всех четырёх узлах пула, по 20 штук, 120 КБ. Сайдкар получил fetch_mode: navigate (дефолт, прежнее поведение), subresource (context.request.get из прогретого контекста) и page_fetch (fetch из страницы). Третий оставлен, потому что теоретически он ближе всего к настоящему XHR, но в замере отказал — выбор сделан измерением, а не рассуждением. Прогрев origin обязателен: рукопожатие QRATOR попадает в куки контекста именно при заходе на страницу, поэтому свип теперь передаёт origin и referer, которых раньше не передавал вовсе. _decode_body распаковывает gzip по магическим байтам — карта офферов приезжает Content-Type: application/gzip, и без этого вызывающий получил бы бинарь в поле "html". Сама карта, к слову, подзапросом всё равно не берётся (279 байт — загрузчик QRATOR), но BFF полнее: 100% фонда против 62% у карты. fetch_mode кладётся в payload только когда он не дефолтный — сайдкар прежней версии не должен получать незнакомый ключ (тот же приём, что с referer в #3247). Тесты: сайдкар 212 passed (новый test_server_fetch_mode.py — 6 проверок), backend 316 passed (новый test_3264_sweep_subresource_mode.py — 5). Три тестовых дублёра _do_fetch/_post_fetch знали старую сигнатуру — обновлены.	2026-08-30 11:24:28 +03:00
bot-backend	44633b0df4	fix(tradein/domclick): свип ходил на QRATOR без кук и вис на PoW каждым запросом (#3264) ... serp.py не передавал куки сессии вообще — слова cookie в файле не было. Свип приходил к QRATOR с чистым браузером и был обязан решать proof-of-work с нуля на каждый запрос. Прод, прогон 5330 (30.08 03:49-03:55): 9 запросов к bff-search-web.domclick.ru, все 9 зависли на челлендже (перезагрузка 1/2, 2/2, отказ), status=failed, 0 лотов. Прокси при этом ротировался (узел 9 → 10) — узел тут ни при чём. Добор с тем же сайдкаром и тем же пулом в ту же ночь взял 37 карточек из 37 без единого блока. Разница ровно в куках. Чинить это стало возможно только сейчас: свип ходит не на ekaterinburg.domclick.ru, а на отдельный хост bff-search-web.domclick.ru, и до правки _cookie_domain (PR #3262) куки легли бы на .bff-search-web.domclick.ru, не совпав с сессией площадки. Теперь оба хоста схлопываются в общий .domclick.ru. Снимок приходит параметром снаружи, а не читается внутри kit: kit не импортирует app.* (strangler-инвариант #2133). Поэтому джоба domclick_city_sweep переопределена продуктовым Handler'ом — build_registry это прямо допускает («последнее слово за продуктом»), а БД читает только app-сторона. Отсутствие сессии не авария: load_session вернул None → свип идёт как раньше, без инъекции, факт логируется один раз. Цена решения — override повторяет вызов kit-джобы целиком и может тихо с ней разойтись. Добавлен тест, который зовёт оба джоба одинаково и сравнивает наборы kwargs, допуская расхождение ровно в cookies. Проверен мутацией: с искусственно добавленным в kit-версию аргументом краснеет, без него зелёный. Тесты: 245 passed, 1 skipped (domclick + parity).	2026-08-30 09:40:21 +03:00
lekss361	1d45ac0747	feat(mera/estimate): ручка фактов дома для предзаполнения формы + гейт «этаж не выше дома» (#3257)	2026-08-29 20:34:00 +00:00
lekss361	5da226a271	fix(mera/estimate): перефит хедоники поверх area-бакетного ratio — крупное жильё занижалось на 21% (#3255)	2026-08-29 20:19:27 +00:00
lekss361	e523c8949c	fix(mera/backtest): свежая фикстура не реплеилась, а разрез по сегментам врал по построению (#3254)	2026-08-29 20:11:11 +00:00
bot-backend	ff0a15d443	feat(tradein/browser): ходить по Домклику как человек — с Referer и с перезагрузкой зависшего рукопожатия ... Добор карточек Домклика упирался в отказ на 11-й карточке: прогон 5298 дал attempted=13, enriched=10, blocked=3. Ручные прогоны в живом браузере брали 91 и 40 карточек без единого отказа. Разбор нашёл два отличия, и оба оказались нашими, а не площадки. 1. Referer не отправлялся НИКОГДА. playwright'овский goto() по умолчанию этот заголовок не шлёт, а параметр `referer`, который он принимает, мы не передавали. Площадка видела десяток появлений подряд прямо на URL карточки, без источника перехода — так не ходит ни один человек. Комментарии в коде при этом уверяли про «органическую навигацию с реальным Referer»; они врали, теперь исправлены. Сайдкар принимает `referer` в теле /fetch и ставит его ТОЛЬКО на целевую навигацию; на origin и якорную вкладку не ставит — туда приходят «сами». Добор Домклика передаёт страницу выдачи, чем переход и является по смыслу. 2. Зависшее рукопожатие не перезагружалось. _wait_out_pow_challenge построен на допущении «страница перезагрузит себя сама после решения PoW»; ручная сессия 29.08 через узел 10 это опровергла — выдача осталась на 401, и пропуск qrator_jsid2 выдался только после ДВУХ перезагрузок, сделанных руками: 102.7с GET → 401, 115.1с GET → 401, 118.4с GET → 200, следом кука-пропуск, и карточка за 6 секунд. Пока мы только опрашивали content(), такая страница жила до таймаута, а бэкфилл засчитывал это в блоки. Теперь после BROWSER_CHALLENGE_RELOAD_AFTER_MS (8с) сайдкар перезагружает сам, не больше BROWSER_CHALLENGE_MAX_RELOADS (2) раз за фетч. Оба пути безопасны на откат: без поля `referer` в теле поведение прежнее, BROWSER_CHALLENGE_RELOAD_AFTER_MS=0 возвращает прежний опрос без навигаций, упавшая перезагрузка не роняет фетч — опрос продолжается в том же бюджете. Тесты: 191 passed в сайдкаре (было 182) — 4 на Referer, 5 на перезагрузку, в том числе «страница ожила сама → лишней навигации нет» и «висит вечно → не больше лимита». Точечные backend-тесты домклика и scraper_kit — 144 passed.	2026-08-29 22:53:11 +03:00
bot-backend	e3f3e8f3b1	Merge remote-tracking branch 'origin/fix/audit-dkp-price' into fix/audit-all	2026-08-30 00:14:23 +05:00
bot-backend	df9dd52996	fix(mera/public): Infinity/NaN во входе — 422, и бюджет считает такие запросы ... Аудит живого сайта 30.08.2026: POST /api/public/mera/coverage с {"lat":56.8,"lon":1e400,...} отвечал 500, и двенадцать таких запросов подряд дали двенадцать пятисоток и ни одного 429. Две независимые поломки в одном месте, обе воспроизведены локально до правки. 1. 500 вместо 422. json.loads принимает Infinity/-Infinity/NaN, а 1e400 даёт inf переполнением. Pydantic отбивает такое поле по границам и кладёт значение в input ошибки, а ответ об ошибке сериализуется json.dumps(allow_nan=False) и падает уже после входа в ответ. Ломается не поле, а сборка ответа об ошибке — одна на всё приложение, поэтому и обработчик один (app/core/http_errors.py), а не валидатор на lon. 2. Лимитер мимо. _enforce стоял первой строкой тела хендлера, а FastAPI валидирует тело позже зависимостей, но раньше тела — до проверки просто не доходило. Та же поправка места, что уже сделана сегодня у _require_public_estimate_enabled: перенос в dependencies. Сделано для всех ручек файла, не только coverage. У /estimate и /estimate/read флаг остаётся первой зависимостью — 429 на выключенной ручке подтверждал бы её существование. Тесты двусторонние: снятие обработчика роняет 4 проверки 422, возврат лимитера в тело роняет проверку бюджета (проверено).	2026-08-30 00:11:56 +05: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
lekss361	6dd8d131ae	feat(mera/estimate): характеристики дома из справочника, а не только из формы (#3242)	2026-08-29 18:06:17 +00:00
bot-backend	c5784e85bc	fix(tradein/domclick): подтверждённый отказ площадки уехал в ветку «сбой транспорта» и перестал банить узел ... #3237 научил сайдкар опознавать статический отказ Домклика самостоятельно — это правильно и работает, но вместе с распознаванием ban-сигнал переехал не туда. Отказ стал приезжать обычной 500-кой: browser_fetcher обнуляет на ней last_response_status, и в detail.py срабатывает ветка except Exception, которая по построению НЕ зовёт report_ban («не подтверждённый маркер-бан, а сбой транспорта», #2600 п.4). Итог на проде (прогон 5287): ban_kinds сменился с platform на unknown, и при шести «статический отказ площадки» подряд в логах сайдкара в scrape_proxy_source_bans не появилось НИ ОДНОЙ записи. Это не косметика счётчиков — platform единственный диагноз, запускающий ротацию IP, поэтому мы продолжали бы долбиться в отказавший узел вместо перехода на свободный. Правка возвращает отказ на ban-путь, сохраняя разделение, ради которого #3237 и делался: - сайдкар кладёт в тело ошибки структурный признак ban_page и апстрим-статус. HTTP-код НЕ меняем: на 500 завязана classify_browser_probe; - SidecarBanPageError — подкласс httpx.HTTPStatusError, поэтому ловля у прочих поставщиков и retry-политика fetch() не замечают нового типа; - detail.py различает две ветки: подтверждённый отказ → report_ban + статус из исключения, транспортный сбой — как раньше. Статус несём отдельным полем, а не через last_response_status: на error-пути fetch() его обнуляет, а у Домклика отказ приходит с 401, без которого классификатор ставит unknown. Подстрокой в тексте исключения признак искать нельзя — _raise_for_sidecar_status обрезает тело до 300 символов, и формулировка отказа менялась дважды за месяц. Тесты держат обе ветки раздельно на всех трёх уровнях: сайдкар (признак есть у бан-страницы, отсутствует у транспортной ошибки), фетчер (тип и upstream_status, включая ловушку bool-как-int из #3196), detail.py (report_ban зовётся / не зовётся, статус доезжает). Closes #3239	2026-08-29 19:12:36 +03:00
bot-backend	6ab13649f6	fix(mera/b2c): выключенная ручка расчёта подтверждала своё существование и печатала схему ... Докстринг обещал: «Отвечаем 404, а не 403: выключенная ручка не должна подтверждать, что она существует». Замер на проде 29.08.2026 (флаг выключен): POST /api/public/mera/estimate {} → 422 + address/area_m2/rooms/consent POST /api/public/mera/estimate {валидное} → 404 POST /api/public/mera/nosuchthing → 401 (rbac) 422 отличается и от 404, и от 401 — то есть подтверждает, что ручка есть, и заодно выдаёт её схему. Причина не в логике гейта, а в его МЕСТЕ: проверка стояла первой строкой тела хендлера, а FastAPI валидирует тело раньше, чем доходит до кода. Гейт перенесён в dependencies=[Depends(...)] обеих ручек — зависимости решаются до разбора тела, и выключенная ручка неотличима от отсутствующей при любом входе. Тест двусторонний и фальсифицирован: возврат вызова в тело красит три теста (включая уже существовавший про 404), обратная правка — снова зелено.	2026-08-29 20:19:15 +05:00
bot-backend	b241e0145a	Merge pull request 'feat(mera/b2c): платёжный роутер, статус-машина и доставка купленного (за флагом)' (#3231) from feat/b2c-payments-router into main	2026-08-29 15:08:33 +00:00
lekss361	195f9f3697	Merge pull request 'chore(tradein): две ручки ротации без читателей и врущий комментарий над ними' (#3232) from chore/3212-dead-rotation-knobs into main	2026-08-29 14:57:40 +00:00
bot-backend	a48070dd89	fix(tradein): миграция платежей 277 → 279 (столкновение номеров) + lock_timeout ... Два параллельных агента взяли ОДИН номер: 277_landing_showcase_runs.sql в ветке витрины и 277_payments_live_checkout_uidx.sql здесь. Обе ветки по отдельности зелёные, но на main второй файл встал бы конфликтом — ровно ловушка из шапки tests/test_migration_numbering.py: номер сверяется с origin/main, а не с чужими открытыми ветками. Заняты сейчас: 275 (метрики), 276+277 (витрина), 278 (публичный токен) → этот 279. Ссылки на номер обновлены в payments.py и test_payments_router.py, включая путь, по которому тест читает предикат частичного UNIQUE. Плюс CREATE UNIQUE INDEX на существующей таблице payments обёрнут в SET LOCAL lock_timeout = '5s' — гейт #2752.	2026-08-29 19:38:38 +05:00
bot-backend	c5315539fa	fix(payments): один живой платёж на оценку — гарантия БД, а не порядка выполнения ... Идемпотентность checkout держалась на «SELECT, потом INSERT» — ровно на том, что шапка модуля называет дефектом. Двойной клик по кнопке оплаты давал два параллельных запроса, два INSERT, два Init и два холда на карте покупателя. - миграция 277: частичный UNIQUE (estimate_id, product_code) по живым статусам + ON CONFLICT DO NOTHING в INSERT. Проигравший гонку не идёт в банк: отдаёт ссылку соперника, если та уже готова, иначе 409; - граница по времени для брошенных попыток: NEW/FORM_SHOWED старше 30 минут переводятся в DEADLINE_EXPIRED. Без неё зависший платёж (нотификации по нему может не прийти вовсе) навсегда отдавал покупателю одну и ту же протухшую PaymentURL. Окно НЕ распространяется на AUTHORIZED и прочие карточные статусы — там деньги уже в игре, разгребать их — работа реконсиляции; - IDOR: checkout читал оценку без _assert_estimate_access. По чужому estimate_id возвращался order_id чужого живого платежа, а order_id — право доступа для /payments/status/<order_id>, отдающего capability-ссылку на отчёт. Проверка ставится только для оценок с владельцем: у анонимной покупки идентичности нет, правом там работает сам estimate_id. Тесты двусторонние, фальсификация прогнана: снятие ON CONFLICT / границы по времени / IDOR-гварда красит ровно один тест каждый раз, два из трёх — по значению ответа.	2026-08-29 19:38:38 +05:00
bot-backend	28e13d5841	feat(payments): роутер checkout/notify, статус-машина и выдача по capability-ссылке ... Не хватало ровно проводки: сервисный слой Т-Банка (PR-C) и схема (PR-B, 233) уже были, HTTP-ручек и статус-машины — нет, как и доставки купленного. Всё за kill-switch PAYMENTS_ENABLED (дефолт false): при выключенном контуре каждая ручка отвечает 503 и не трогает ни банк, ни платёжные таблицы, поэтому merge на проде не меняет поведения. Идемпотентность целиком отдана БД (UNIQUE миграции 233 + ON CONFLICT DO NOTHING), а не паре «проверить-потом-вставить»: между проверкой и вставкой проходит параллельный ретрай банка, и товар выдаётся дважды. Признаком «выдача состоялась» служит payment_notifications.processed_at, а не сам факт строки — иначе падение процесса между записью нотификации и выдачей оставило бы клиента без отчёта при списанных деньгах. Доставка — capability-ссылка /api/v1/trade-in/r/<token>: токен лежит в payment_entitlements.subject (ref_id остаётся estimate_id, на нём держится UNIQUE «выдали один раз»), режется из GlitchTip-событий и открыт в rbac отдельным узким префиксом. Тело GET /estimate/{id} вынесено в load_estimate, чтобы у второго права доступа был тот же загрузчик, а не третья копия гейта читаемости.	2026-08-29 19:38:37 +05:00
bot-backend	dcfea2ad39	test(mera/b2c): пинит kwargs делегации анонимного расчёта, а не факт вызова ... Весь анти-абузный контур публичной ручки (анонимная квота cookie+IP, семафор, 503 вместо 502, consent-гейт) держится на одном аргументе: в app.api.v1.trade_in.estimate уходит x_authenticated_user=None. Проверял это ноль тестов: estimate везде замокан AsyncMock, который принимает любую сигнатуру, — подмена None на чтение заголовка запроса оставляла все 14 тестов зелёными, а публичная форма начинала считать от чужого имени мимо квоты. Новый тест шлёт запрос С заголовком X-Authenticated-User: admin и сверяет фактические await_args.kwargs; заодно требует, чтобы аргументы ехали по имени (позиционный вызов обесценивает сверку) и чтобы аргумент вообще присутствовал (дефолт эстиматора — чужая гарантия, не наша). Проверено падением: подмена на request.headers.get даёт «пришло: 'admin'». Там же UPDATE токена: параметры сверялись только по хэшу, id строки — нет. Теперь пинится result.estimate_id: токен обязан вешаться на только что посчитанную оценку. Проверено подменой параметра — красный по значению. test_read_filters_by_expiry_and_hash оставлен текстовым: живого Postgres с миграцией 278 здесь нет, а поведенческий тест, ни разу не прогнанный, — это ещё один зелёный по построению. Вместо этого в самом тесте написано, что он проверяет (предикат есть в тексте SQL, в параметрах хэш) и чего НЕ проверяет (сессия — MagicMock, запрос не исполняется, протухший токен не отсекается), и чем его заменить, когда БД появится.	2026-08-29 19:28:37 +05:00
bot-backend	2d4daceb2f	feat(mera): анонимный расчёт и капабилити-ссылка на его бесплатную часть ... Публичный контур умел только подсказки и пробу покрытия: полный расчёт закрыт RBAC, а результат анонима нельзя было прочитать повторно — _assert_estimate_access отдаёт 404 на строку с created_by IS NULL всем, кроме админа, то есть расчёт жил ровно в теле POST-ответа и не переживал перезагрузку страницы. POST /api/public/mera/estimate делегирует в app.api.v1.trade_in.estimate (копии логики нет — иначе публичная когорта разъедется с платной) и отдаёт наружу только бесплатную часть: число аналогов и вердикт покрытия из той же coverage_probe. Цены, прогнозы и списки аналогов остаются в БД для платного контура. Согласие 152-ФЗ обязательно и строго True на уровне схемы, поэтому отказ происходит до входа в хендлер — раньше, чем адрес физлица дошёл бы до БД. POST /api/public/mera/estimate/read читает бесплатную часть по токену (secrets.token_urlsafe(32), в БД только sha256, срок жизни 7 дней, миграция 278). Токен едет телом: access-лог Caddy пишет URI целиком, и капабилити-ссылка в пути легла бы в файл рядом с IP посетителя — тот же довод, по которому POST'ом сделан /suggest. Постоянный путь заодно не требует префиксной ветки в rbac._PUBLIC_PATHS. Всё закрыто флагом public_estimate_enabled (дефолт false → 404): включение открывает запись ПДн и требует решения владельца вместе с правкой политики.	2026-08-29 19:28:37 +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	1141035899	chore(tradein): две ручки ротации, которых не осталось читателей, и врущий комментарий над ними ... proxy_rotate_attempts / proxy_rotate_attempt_timeout_s тюнили ретраи changeip-GET. Сам changeip снят в #2616 шаг 2 (аккаунт mobileproxy закрыт, ссылки нет), и с тех пор ручки живут пламбингом: Settings -> property адаптера -> поле протокола ScraperConfig -> и всё. Ни одного потребителя, только четыре теста, которые заполняют их при сборке конфига. Комментарий над ними в contracts.py оправдывал их сохранение так: «оставлены как budget-верхняя-граница для app.tasks.avito_detail_backfill wait_for» — но wait_for там берёт СОСЕДНЕЕ поле, avito_proxy_rotate_settle_s (avito_detail_backfill.py:249). То есть комментарий приписывал этим двум полям работу третьего и тем самым прикрывал их мёртвость. Соседние ручки проверены и ОСТАВЛЕНЫ, они действительно читаются: * avito/cian/yandex_proxy_max_rotations — pipeline._max_rotations; * avito_proxy_rotate_settle_s — asyncio.wait_for в avito_detail_backfill. Заодно сжат комментарий в config.py: перечисление истории changeip заменено на то, что нужно знать сейчас — кто читает оставшиеся две ручки и где живая ротация (ASOCKS_API_TOKEN / proxy_rotation, #2611). ruff clean, 4974 passed / 37 skipped.	2026-08-29 17:07:04 +03: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	301d803ac5	test(tradein/domclick): второй assert_called_once_with на конструкторе (#3197 ч.1) ... CI Trade-In / backend-tests упал на tests/tasks/test_domclick_detail_backfill.py:165 — там тот же хрупкий assert_called_once_with, что уже был поправлен в tests/test_3118_domclick_warm_context.py: он фиксирует ТОЧНУЮ сигнатуру вызова BrowserFetcher и ломается на любом новом kwarg. Лечение то же самое: assert_called_once() + точечная проверка source/endpoint/ reuse_context. Полная проводка пула покрыта отдельным tests/test_3197_domclick_proxy_pool_wiring.py. Причина пропуска: локально прогонялась выборка из трёх файлов, а не весь набор. Теперь прогнан весь: 4974 passed, 37 skipped, 0 failed.	2026-08-29 15:40:56 +03: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
bot-backend	663f426d4c	fix(tradein/domclick): отказ с кодом 401 классифицировался как причина неизвестной природы (#3196) ... Замер на проде 2026-08-29: страница отказа ДомКлика при HTTP 401 — РОВНО 26 624 байта, байт в байт та же, что снималась 28.08 под кодом 403. Ни PoW, ни QRATOR, ни капчи. Приходит одинаково и с валидной сохранённой сессией (16 куков из domclick_session), и полностью анонимно — значит это не «сессия отвергнута», а WAF-отказ с подменённым кодом ответа. В таблице классификатора 401 не было (403/429 → platform, 5xx → infra), поэтому все три пробы подряд дали ban_kind='unknown' — ровно то, что #3196 и должен был убрать. Механика диагноза при этом рабочая: статус доезжает от page.goto до исключения целым, шов blocked.status = status подтверждён живым 401 на проде. Правка доменная — в _ban_kind_of_block домкликового таска, а не в общей scraper_kit.browser_fetcher.ban_kind_from_status: у других поставщиков 401 обычно значит «наша сессия протухла», это наша сторона, и метка 'platform' там зря запустила бы ротацию IP (#2611).	2026-08-29 12:19:18 +03:00
lekss361	cdcb152d76	Merge pull request 'fix(tradein/scrapers): ABORT-лог называл серию блоков, хотя рвал прогон по доле' (#3201) from fix/3184-abort-log-names-wrong-criterion into main ... Reviewed-on: #3201	2026-08-28 20:27:36 +00:00
bot-backend	bf3214b9e4	fix(tradein/scrapers): диагноз блока брался из текстовых маркеров чужой площадки, а не из HTTP-статуса (#3196) ... Сайдкар вообще не читал код ответа page.goto: страница классифицировалась только по маркерам, снятым с Авито. Домклик отдаёт статическую `403 | Домклик` на 26 624 байта, где нет ни одного такого маркера (замер прода 28.08.2026) — она уезжала наверх как валидный HTML, парсер не находил состояние, и прогон получал блок неизвестной природы. За 14 дней все 14 прогонов домклика легли с ban_kind='unknown'; у Яндекса счётчика blocked не было вовсе, поэтому ветка перевода прогона в 'banned' была недостижима по построению — ноль банов. - browser/server.py: статус целевой навигации сохраняется per-provider и доезжает в тело /fetch аддитивным ключом "status" (ключ "html" не тронут); 403/429 с маркерами челленджа больше не ждут PoW — ждать нечего, статическая страница сама себя не перезагрузит. Наверх идёт BanPageDetectedError, а не заглушка: вернув её контентом, воскресили бы #3045. - scraper_kit/browser_fetcher.py: BrowserFetcher.last_response_status + ban_kind_from_status (403/429 → platform, 5xx → infra, прочее → None). Поток управления не менялся: fetch() по-прежнему отдаёт str. - domclick: DomClickBlockedError несёт .status — один тип исключения на маркер-детект и на сбой фетча разводится без размножения типов; прогон передаёт перепись диагнозов в mark_backfill_finished. - yandex: появился счётчик blocked, оживляющий ветку бана. Серии блоков и промахов парсера считаются РАЗДЕЛЬНО: иначе четыре промаха плюс один 403 пятым давали 'banned' с переписью {platform: 1}. - cian: ban_kinds наполняется только диагностируемым статусом. HTTP 200 с пустым разбором — дрейф разметки на нашей стороне, а не отказ площадки; записав его блоком, мы бы штамповали фиктивные баны у здорового источника (13 done против 1 banned за 14 дней). Инвариант: непустой ban_kinds ⟺ виден ответ 403/429/5xx. Значения остаются в пределах CHECK scrape_runs.ban_kind. Известный пробел: шов providers/domclick/detail.py `blocked.status = status` тестами не покрыт — существующие домкликовые тесты подают исключение готовым моком и боевой fetch_detail не исполняют.	2026-08-28 23:21:54 +03:00
bot-backend	8176e8d167	fix(tradein/scrapers): ABORT-лог называл серию блоков, хотя рвал прогон по доле ... Прод-прогон 5210 оборвался по ratio-критерию — 14 блоков из 20, ровно порог 0.7 — и отчитался строкой «ABORT -- 1 consecutive blocks». Число верное: последняя серия в тот момент действительно равнялась единице (19-я попытка успех, 20-я блок). Величина не та. Читатель лога видит цифру, по которой обрыва быть не могло, и идёт искать несуществующий баг в брейкере. Причина: #3184 заменил критерий обрыва на долю в скользящем окне, а текст лога остался от прежнего критерия «N подряд» — то есть ровно та же болезнь, которую #3178 лечил у соседней строки (литерал «IP rate-limited» вместо измеренной причины). - BlockRatioBreaker.abort_reason() возвращает "ratio" / "safety_net" / None; should_abort() выражен через него, поведение не меняется. - abort_explanation() даёт текст с той величиной, по которой обрыв и произошёл: доля печатает «доля блоков 14/20 в окне (порог 70%)», safety-net — «5 блоков подряд без единого успеха (снапшот 5 короче окна 20)». - counters["abort_reason"] — чтобы причина обрыва читалась SQL-запросом по scrape_runs, а не грепом контейнера. Ключа нет, если прогон не обрывался. Тесты (проверено мутацией источника — на прежнем сообщении оба падают): - ratio-обрыв на раскладке прогона 5210 (серия на обрыве = 1) требует «14/20» в логе и отсутствия слова consecutive; - safety-net требует «5 блоков подряд» и отсутствия «доля блоков» — без этого зеркала первый тест проходил бы и у сообщения, всегда печатающего долю; - прогон без обрыва (13/20) не пишет abort_reason в counters. Refs #3184, #3178	2026-08-28 23:04:07 +03:00
bot-backend	5be64c6688	fix(tradein/scrapers): хранилище авторизованной сессии Яндекс.Недвижимости (#3195)	2026-08-28 19:02:05 +00:00
bot-backend	49b70a67f3	fix(tradein/scrapers): обрыв по серии блоков рвал каждый прогон, включая здоровые (#3188)	2026-08-28 18:22:25 +00:00
bot-backend	e685f96107	fix(tradein/scrapers): диагноз блока терялся при схлопывании, а в алерт шла непроверенная причина (#3183)	2026-08-28 17:15:02 +00:00
bot-backend	51027d8b02	fix(tradein/ingest): rosreestr_dkp_import курсор переживает рестарт (#3168) ... last_id жил только в памяти процесса (import_rosreestr_dkp, scheduler.py): heartbeat писал его в scrape_runs.counters каждый батч (комментарий рядом прямо называл это чекпоинтом), но при старте last_id всегда инициализировался литералом 0 — обрыв (деплой/OOM/рестарт хоста) откатывал прогресс и заставлял пере-сканировать источник с начала. Разведка: из пяти backfill-циклов issue (avito_detail_backfill, house_imv_backfill, cian_history_backfill, yandex_detail_backfill, geocode_missing_listings) ни один не имеет этого дефекта — все устроены как WHERE ... IS NULL/NOT EXISTS ... LIMIT, естественно резюмируемы без курсора. Единственный код, буквально описанный в issue (строки/SQL/комментарий), это шестой, не входящий в таблицу backfill — rosreestr_dkp_import. Фикс — _resume_dkp_cursor(db, run_id): - кандидат — последний прогон source='rosreestr_dkp_import'; - резюмится только незавершённый штатно прогон: status running/zombie, либо done с counters.interrupted=1 (SIGTERM-drain — эта ветка раньше считала последующий full rescan штатным поведением, теперь помечает себя как прерванную и резюмится наравне с zombie); - потолок возраста чекпоинта — 24ч, старше — 'checkpoint_stale', старт с 0; - чистый 'done' (полный проход) не резюмится — иначе ON CONFLICT DO UPDATE перестанет ловить правки уже импортированных сделок при следующем проходе. Вердикт и per-batch чекпоинт пишутся через kit_runs.update_heartbeat (merge `counters || :counters`) вместо локального runs_mod.update_heartbeat (полная замена) — иначе resume-вердикт стирался первым же heartbeat'ом батча. Тесты: tests/test_3168_backfill_cursor_resume.py — резюм с сохранённого last_id, резюм после SIGTERM-drain, отказ резюмить чистый done, отказ резюмить протухший (>24ч) чекпоинт, merge не стирает посторонние ключи. Обратимость проверена вручную (временный откат _resume_dkp_cursor красил 6 из 8 тестов).	2026-08-28 01:08:21 +03:00
bot-backend	bdb9b64b03	Merge pull request 'fix(tradein/domclick): исчерпание пула прокси помечалось как отказ сбора (#3118)' (#3174) from fix/3118-domclick-no-proxy into main	2026-08-27 22:03:56 +00:00
bot-backend	ade1a065d6	fix(tradein/domclick): исчерпание пула прокси свипа теперь infra-бан, не отказ сбора ... NoProxyAvailableError поднимается из BrowserFetcher.__aenter__ (_acquire_lease) ДО первого HTTP-запроса, когда пул прокси пуст — это НАША инфраструктура, не блокировка площадкой. У run_avito_full_load/run_cian_full_load/run_yandex_full_load уже есть выделенный except NoProxyAvailableError -> mark_banned(ban_kind='infra'), у run_domclick_city_sweep его не было: исключение проваливалось в общий except Exception внутри SERP-фазы, _scraper_ref оставался пустым, и честный статус ниже видел "0 лотов + errors>0" -> mark_failed("fetch errors — 0 listings") с ban_kind=NULL. Прод-факт: run 5023 (27.08) умер за 51 мс, errors_count=1, ban_kind=NULL — неотличимо от честного отказа сбора площадкой. Добавлен except NoProxyAvailableError перед generic except Exception (порядок важен: класс — подкласс RuntimeError). Обработчик зеркалит avito/cian/yandex: mark_banned + ban_kind_of_exception(exc) (даёт BAN_KIND_INFRA), и сохраняет унаследованный чекпоинт (skip_buckets) вместо потери его на нашем же отказе. Тест test_3118_domclick_no_proxy.py проверен на обратимость: без обработчика падает (mark_failed вместо mark_banned), с обработчиком — проходит.	2026-08-28 00:54:48 +03:00
bot-backend	dc793e8701	fix(tradein/yandex): чекпоинт combo ставился до save_listings, не после ... _on_combo в run_yandex_city_sweep делал done_combos.add(combo_label) ДО вызова save_listings. Отказ save_listings перехватывается (осознанно — одна упавшая единица не должна ронять весь sweep) и логируется, но combo уже был отмечен пройденным и уходил в heartbeat done_buckets. Следующий resume брал skip_combos из done_buckets (членство в множестве — само по себе корректно, не трогал) и пропускал этот combo навсегда: молча, прогон завершался штатно, просто сегмент выдачи не собирался никогда. Тот же инвариант "отмечаем пройденным только после успешного save", что уже есть у страницы в run_avito_newbuilding_sweep (_saved_ok), якоря в run_avito_city_sweep (_anchor_ok) и бакета в run_cian_full_load (_mark_bucket) — применил к combo. Heartbeat пишется в любом случае (и при отказе save тоже), иначе reap_zombies посчитает живой прогон мёртвым. Тесты: test_3170_yandex_combo_checkpoint.py — combo с упавшим save не попадает в done_buckets, успешный (включая пустую выдачу) — попадает. Обратимость проверена: с возвращённым дефектом (git stash) первый тест красный, со снятым — зелёный вместе с существующим test_3074_yandex_ sweep_checkpoint.py (6/6).	2026-08-28 00:48:55 +03:00
bot-backend	5a410687ac	feat(tradein/scraper): чекпоинты для avito_newbuilding_sweep — страница как единица (#3074) ... Последний длинный свип без возобновления: при обрыве прогон начинался с первой страницы, а собранное терялось целиком — save_listings вызывался один раз на весь sweep. Единица возобновления — страница выдачи, по образцу якорей в city sweep. `_paginate_sweep`/`fetch_newbuildings` получили `start_page` (уже собранные страницы не запрашиваются) и колбэк `on_page`, который вызывается только после того, как страница пройдена до конца. Сохранение стало постраничным, номера пройденных страниц копятся в `scrape_runs.counters.done_buckets` мержем через `update_heartbeat`. Два инварианта, без которых фича вредна: 1. В чекпоинт попадает только страница, чьи лоты СОХРАНЕНЫ. Отказ save_listings перехвачен и прогон продолжается, но отметить такую страницу пройденной значило бы, что следующий прогон её пропустит и объявления оттуда не соберутся никогда — молча, потому что прогон завершится штатно. 2. Подхват начинается с ПЕРВОЙ несобранной страницы, а не с max+1. Дыра в чекпоинте возможна ровно из-за п.1, и max+1 перепрыгнул бы её навсегда. Страницы после дыры перечитаются — это дешевле потери и безопасно, повторная запись схлопывается по dedup_hash. Оба инварианта закрыты тестами, которые падают при их нарушении.	2026-08-28 00:10:56 +03:00
bot-backend	c01ec805df	fix(tradein/tgbot): в логе сетевого сбоя не было причины — только пустота после двоеточия ... Замер на проде 27.08: `getUpdates` падает 23 раза в сутки, 14 из них за один час. Ретрай почти всегда чинит с первой попытки, поэтому сообщений не теряется — теряется возможность понять, что происходит: network error (попытка 1/3): — retry через 2s После двоеточия пусто. У httpx.ReadError и httpx.ConnectError `str(exc)` пуст, а тип исключения в строку не попадал. По такому логу не отличить таймаут от обрыва соединения от сброса TLS, то есть 23 события в сутки не дают ни одной зацепки. Сеть при этом цела: сырой TLS до Telegram проходит 6 из 6 попыток за ~0.16s. Тип добавляется к тексту, а не вместо него: на исключениях с внятным сообщением диагностика не должна стать беднее прежней. Оба конца закреплены тестами — с пустым текстом и с непустым. Closes #3156	2026-08-27 21:58:51 +03:00
bot-backend	8cdb195e18	fix(tradein/geocode): бюджет прогона не был потолком — проверялся только между батчами ... `run_geocode_missing_listings` рекламирует `budget_sec` как максимальное время прогона, но проверка стояла после возврата из батча. Внутри батча цикл шёл по всем 200 адресам и часов не смотрел, то есть фактический потолок был `budget_sec + один полный батч`. Замер: прогон 5017 (27.08, `budget_sec=1800`) шёл 3150 с — 175 % бюджета, и вышел не по бюджету, а по дренажу: бюджетная ветка за 52 минуты не выполнилась ни разу. Пока адрес стоил ~1.9 с это терялось в шуме. После общего ограничителя темпа Nominatim (#2953) средняя цена 4.5 с, а на трудном хвосте (tier-1 + до 4 typo-вариантов под паузой 1 с, плюс retry×3) — до 33 с. Полный батч из таких адресов уезжает на ~110 минут поверх бюджета, при окне расписания 06:00–09:00. Дедлайн теперь передаётся В батч и проверяется на каждом адресе. Оборванный батч — штатный исход: `geocode_tried_at` проставлен только у обработанных пар, остальные попадут в выборку следующего прогона. Отдельный флаг `budget_exhausted` нужен потому, что `addresses_total` на оборванном батче равен размеру ВЫБОРКИ (== batch_size) — ветка дренажа `addresses_total < batch_size` не сработала бы, и обёртка крутила бы цикл дальше. Тест на это падает без флага (проверено снятием ветки). Тесты: 5 новых, все три несущие проверки падают без соответствующей правки. 37 passed локально. Closes #3151	2026-08-27 19:10:53 +03:00
bot-backend	cf3d4850e2	fix(tradein/scrapers): три прод-пути остались на chrome120, пока kit ушёл на chrome146 ... #3034 свёл impersonate к единственной константе внутри scraper_kit и поднял профиль до chrome146. Сторож литерала сканирует только пакет, а его докстрока объявила остальное «отдельным периметром вне scope», сославшись на #2361 F4a. Периметр не спящий — он ходит в сеть каждый день, а #2361 к тому моменту был закрыт, то есть отсылка вела в никуда. На chrome120 оставались: app/services/cian_session.py:164 верификация куки Циана app/services/yandex_address_backfill.py:153 бэкфилл адресов app/tasks/yandex_detail_backfill.py:303 detail-бэкфилл Разрыв в 31 мажорную версию живёт в TLS-отпечатке (JA3/JA4), а не в строке User-Agent, поэтому сменой прокси он не лечится. ПРО ЦИАН ОТДЕЛЬНО. По #2673 оценка Циана мертва с 29 июня — «куки протухли, ни одной новой строки 37 дней». Путь, которым проверяется живость этих куки, всё это время представлялся площадке браузером двухлетней давности. Причину этим не объявляю: утверждаю, что при таком отпечатке отличить «куки протухли» от «нас узнали по рукопожатию» нечем. ТЕСТ ЗАКРЕПЛЯЛ ДЕФЕКТ. test_cian_session прибивал chrome120 гвоздём: подъём профиля в kit ронял бы этот тест, а «починкой» выглядел бы возврат к устаревшему профилю. Теперь тест сверяется с DEFAULT_IMPERSONATE. Сторож литерала расширен на backend/app — без этого периметр возвращается молча, что уже один раз и произошло. Намеренно НЕ входят tests/fixtures/** (номер профиля там — часть записи о том, чем снят фикстур-HTML) и scripts/** (разовые инструменты, в прод-путях не участвуют). Исторические замеры в комментариях сохранены как замеры: «curl_cffi с kit-профилем (на момент замера — Chrome 120)» вместо переписывания истории. Проверено: сканер сторожа на дереве даёт ноль нарушителей, на подсаженном литерале краснеет; все изменённые модули компилируются. Refs #3148	2026-08-27 18:18:05 +03:00