1083 commits

Author	SHA1	Message	Date
bot-backend	be9aa2f907	Гейт на ВСЕ 34 проводки + запрет вложенных бюджетов (ревью #3460) ... Сценарный тест ловил одну проводку из 34 — ту, через которую сам и шёл (`geocoder._cache_get`). Мутационный прогон ревьюера: возврат голого `asyncio.to_thread` в 5 из 6 других мест тест НЕ краснит, то есть регресс «кто-то вернул вызов в голый вид» прошёл бы мимо CI в 33 случаях из 34. `test_no_bare_to_thread_over_request_session` читает исходники geocoder и estimator (через `module.__file__`, не по относительному пути — он зависел бы от cwd прогона) и требует нуля живых `asyncio.to_thread(`. Оба модуля сейчас на нуле, поэтому гейт без списка исключений. Фальсификация — голый `to_thread` у `_fetch_anchor_comps` (estimator:4973, сценарным тестом не покрыт): гейт краснеет с номером строки. Второе: защита `run_db_thread` одноразовая — `except asyncio.CancelledError` ловит ОДНУ отмену, вторая вылетает из самого `asyncio.wait([step])`, и поток остаётся сиротой. Живых путей нет (`_with_budget` нигде не вложен, Starlette не отменяет задачу на дисконнекте, uvicorn стартует без `--timeout-graceful-shutdown`), поэтому кода не трогаю — фиксирую инвариант «не вкладывать бюджеты» в докстринге `_with_budget`, чтобы вложение не завезли как безобидное. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 13:57:49 +05:00
bot-backend	c251c02f1e	Отмена по бюджету больше не оставляет сироту в сессии запроса (#3449) ... `asyncio.to_thread` отменить нельзя: по истечении бюджета (`_with_budget` = `asyncio.wait_for`, у геокодера 12 с) снимается только ожидание со стороны loop'а — поток продолжает работать с ТОЙ ЖЕ `Session`, что и весь запрос. Вызывающий тем временем идёт дальше: следующий источник, `_fetch_anchor_comps`, `_persist_estimate_and_commit`. Два потока в одной `Session` дают «another operation is in progress» / InvalidRequestError на СЛЕДУЮЩЕМ шаге. У источников эту ошибку глушит `except` вокруг вызова, у персиста оценки не глушит никто — 500 и потерянная оценка клиента. `app/core/db.py: run_db_thread` — ТОЛЬКО защита от сироты: `ensure_future` + `shield`, на отмене дождаться потока (`asyncio.wait`), прочитать `step.exception()` (иначе asyncio печатает «Task exception was never retrieved» без контекста) и пробросить отмену. Commit/rollback туда НЕ вынесены: посреди геокодинга commit зафиксировал бы частичное состояние оценки. `estimator._db_step` переписан поверх и добавляет свои commit/rollback сам — его поведение не меняется, гейт tests/test_3408_db_step_cancel_orphan.py остаётся зелёным. Заменено 34 вызова, работающих по сессии запроса: 12 в geocoder.py (кэш-чтение и записи, геопортал, кадастр, houses, reverse, suggest), 19 в estimator.py (в т.ч. `_backfill_house_fias`, `_save_yandex_history_items`, `_fetch_anchor_comps`, `_price_from_inputs` с db-резолверами, персист оценки, `_fetch_price_trend`, `_is_premium_building`), 2 в api/v1/geocode.py, 1 в api/v1/privacy_admin.py. Не тронуты вызовы со СВОЕЙ сессией: `user_events.schedule_event` (внутри `record_event` свой `SessionLocal`) и `sber_index` (сессия задачи планировщика, отменять её некому). Гейт по значению — tests/test_3449_geocoder_cancel_orphan.py: отмена по бюджету во время шага БД геокодера, следом ГОЛЫЙ `to_thread(db.execute, ...)` (образец персиста); проверяется, что он не вошёл в сессию, пока сирота ещё в ней. На исходном коде тест краснеет: conflicts == 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 13:20:44 +05:00
bot-backend	10ffa93a1c	fix(support): доставленное сообщение не теряется при сбое БД, отказы Telegram расходуют бюджет ... Два последних дефекта из разбора телеграм-стека, оба в ручках веб-поддержки. Предыдущие три PR (#3456, #3457, #3458) чинили клиент и мост; эти — сами ручки. ## Сбой БД уже ПОСЛЕ доставки в топик Порядок «сначала Telegram, потом БД» осознанный, но блок записи не был обёрнут ничем, в отличие от шага отправки. `SQLAlchemyError` там означал: сообщение оператору доставлено, а клиент получил 500. Дальше по цепочке — пользователь шлёт повторно, в топике дубль, а на осиротевшее зеркало оператор отвечает в пустоту, потому что треда в БД нет и мост на реплай пишет только WARNING. Обе ручки теперь ловят `SQLAlchemyError` вокруг блока БД, тихо откатывают сессию, предупреждают оператора реплаем к доставленному зеркалу и отдают клиенту успех. Успех, а не отказ: доставка правда состоялась, и отказ спровоцировал бы ровно тот дубль, которого избегаем. Анонимная ветка на этом пути дополнительно ставит куку, хотя штатно ставит её только на успехе: треда нет, но идентичность посетителя обязана пережить сбой, иначе следующее сообщение заведёт второй тред. ## Успеха мало — клиент должен об этом узнать Первая версия правки отдавала успех молча, и это было неотличимо от тишины. Фронт выбрасывает тело POST и рендерит переписку только из GET, а сообщения там нет: поле ввода очищается, в списке пусто, баннера нет. Пользователь решает, что не отправилось, и шлёт снова — тот самый дубль. Нашло adversarial-ревью, и это подтверждено чтением `useSupportChat.ts` и `SupportChatPanel.tsx`. Поэтому `SupportMessageOut` получил поле `persisted` со значением `True` по умолчанию — все существующие пути и `GET /support/messages` отдают его без изменений. На пути деградации приходит `False`, и панель показывает рядом с композером предупреждение: сообщение получено оператором, но в переписке его не будет, отправлять ещё раз не нужно. Баннер гаснет на следующей нормально записанной отправке. Анонимный виджет рендерит ту же панель и получает это поведение автоматически. Текст предупреждения оператору тоже переписан: он больше не рассчитывает на то, что клиент напишет снова, и прямо говорит, что ответить через бота не получится. ## Рейт-лимит переставал считаться при недоступном Telegram `retry_after()` — это peek, а `record()` звался только на успехе. Верно для «не наказывать за чужую аварию», но имеет обратную сторону: пока Telegram лежит, лимита нет вообще, и каждый повтор стоит до четырёх попыток к api.telegram.org, не расходуя ни один бюджет. Двух-трёх вкладок с авто-повтором хватает, чтобы выесть лимиты группы ровно тогда, когда канал и так еле жив. Добавлен отдельный счётчик отказов на тех же ключах: пять подряд в окне тридцати секунд включают cooldown, и ручка отвечает 429 не доходя до Telegram. Пять подряд на живом канале практически недостижимы, а `reset()` на успехе стирает историю — считаем именно подряд. Тридцать секунд заведомо короче реальной недоступности, так что после восстановления пользователя не наказывают. Основной «успешный» бюджет и non-destructive peek не тронуты. `SlidingWindowLimiter.reset(key)` добавлен аддитивно, с оговоркой в докстринге, что лимитерам-бюджетам он противопоказан. Барьер рассчитан на несколько вкладок с авто-повтором, а не на одиночного последовательного клиента: один отказавший запрос сам занимает до двадцати трёх секунд, и пять таких в окно не укладываются. Это принято сознательно — ловить одиночку значило бы наказывать обычного пользователя за чужую аварию. ## Тесты Отказ БД в обеих ручках: клиент получает успех с `persisted=False`, оператору уходит предупреждение, текст обращения в него не попадает, 500 не возникает. Отказ самого уведомления ручку не роняет. Серия отказов включает cooldown, и до Telegram запрос не доходит. Окончание окна cooldown снимает. Успешный путь и существующий рейт-лимит не изменились. Бэкенд: 117 passed, ruff чистый. Фронт: type-check чистый, lint без новых замечаний.	2026-09-12 10:53:45 +03:00
bot-backend	1fa65eba6b	fix(tg): связь с Telegram не встаёт колом, ответ оператора не теряется ... Замер прода за сутки 12.09.2026: 576 строк `network error` в логе `tradein-tgbot` и 7 полных исчерпаний бюджета ретраев, после которых падала итерация poll loop. Три причины, все подтверждены на коде и в рантайме. ## Ответ оператора мог пропасть навсегда `process_update` заканчивался безусловным `finally: save_offset(update_id)`. Замысел верный — «ядовитый» апдейт не должен блокировать поток, — но он не отличал неисправимый апдейт от транзиентного сетевого отказа. Оператор отвечает клиенту в топике, `copy_message` падает по сети, `TelegramNetworkError` улетает в общий `except Exception`, offset сдвигается. Telegram этот апдейт больше не отдаст, `record_message` не выполнился, оператор уверен, что ответил. Следа нет нигде, кроме строчки в логе. Теперь `process_update` возвращает `bool`. На `TelegramNetworkError` делается `rollback()`, offset НЕ сохраняется, возвращается `False`, и `run_poll_loop` прерывает разбор пачки — offset у Telegram единая «высшая отметка», подтверждение любого следующего апдейта неявно подтвердило бы и этот. Остаток пачки Telegram отдаст заново. Переигрывания ограничены сверху `_MAX_NETWORK_REPLAYS = 3`: без потолка «вечно недоставляемый» апдейт заклинил бы очередь навсегда, а это хуже потери одного сообщения. На потолке offset всё-таки двигается, но с `logger.error` и с `chat_id`/`message_id`, по которым человек найдёт ответ в топике и перешлёт руками. Текст переписки в лог по-прежнему не идёт. Дубли: `TelegramNetworkError` означает исчерпанный бюджет ретраев, при этом запрос мог дойти до Telegram, а ответ потеряться. Переигрывание тогда доставит сообщение второй раз. Это осознанный at-least-once компромисс — дубль видят и клиент, и оператор, а тихая потеря не видна никому. Полная идемпотентность по паре (update_id, target_chat_id) потребовала бы новой персистентной таблицы ради редкого случая; вместо неё число дублей жёстко ограничено сверху. Ветка `except TelegramApiError` с разбором `error_code == 403` («бот заблокирован») не тронута — там повтор действительно ничего не изменит. ## Таймаут задавался скаляром, поэтому connect ждал сорок секунд `httpx.AsyncClient(timeout=effective_timeout)` разворачивается в connect=read=write=pool. Для `getUpdates` бюджет ответа 40 секунд (30 держит Telegram плюс запас), и те же 40 секунд уходили на установку соединения — при живом connect в 0.036 секунды. Худший цикл: четыре попытки по 40 секунд плюс backoff, около трёх минут, в течение которых бот не видит ответов оператора. В логе это ровно те разрывы: 06:40:10, 06:42:22, 06:43:35. Теперь `httpx.Timeout(connect=5, read=<бюджет вызывающего>, write=10, pool=5)`, значения в именованных константах. Запас `+10s` у `get_updates` относится к read, докстринг поправлен. ## Клиент создавался заново на каждую попытку `httpx.AsyncClient` стоял ВНУТРИ цикла ретраев — keep-alive не было вовсе: полный TCP+TLS-хендшейк на каждый запрос и на каждый повтор, и заново кидался кубик «встанет ли коннект». Для long-polling это была основная статья сетевых отказов. Плюс три HTTP-ручки создавали `TelegramClient` на каждый входящий запрос. Теперь один ленивый переиспользуемый `AsyncClient` на экземпляр, с `aclose()` и `async with`. Общий клиент приложения живёт в новом `app/services/tgbot/shared.py`, создаётся и закрывается в lifespan; воркер бота держит свой на время поллинга. `keepalive_expiry` задан явно: дефолт httpx — 5 секунд, и с ним пул не давал бы ничего там, где нужнее всего. Poll loop переиспользует соединение и так, а вот веб-поддержка шлёт раз в минуты и за 5 секунд теряла бы его каждый раз. Плата за длинный keep-alive — шанс взять из пула закрытое той стороной соединение; httpx отдаёт это как `RemoteProtocolError`, который ретраится с #3457. ## Уведомления оператору шли с воркерным бюджетом внутри poll loop Обе отправки в топик («бот заблокирован», «веб-чат не поддерживает медиа») звались без своего бюджета, то есть с дефолтом в 5 ретраев и backoff до 30 секунд. Одна такая отправка стопорила весь цикл на минуты, а её отказ решал судьбу апдейта. Вынесены в `_notify_topic` с узким бюджетом и собственным `except`: провал вторичного действия больше не отменяет основную ветку. ## Тесты `tests/services/tgbot/test_shared.py` — новый, на жизненный цикл общего клиента. В `test_bridge.py` — сетевой отказ оставляет offset нетронутым и апдейт переигрывается, потолок разблокирует поток, отказ уведомления не отменяет основную ветку, прежнее поведение на 403 не изменилось. В `test_client.py` — раздельные таймауты доезжают до httpx per-request, два вызова используют один `AsyncClient`, `aclose()` его закрывает. Прогон по затронутым файлам: 127 passed. Ruff check и format чистые. Прокси намеренно не добавлялся: замер был на восьми запросах, это не статистика, и решение инфраструктурное. Если обрывы останутся — мерить сотней попыток отдельно.	2026-09-12 10:13:44 +03:00
bot-backend	087c48fef5	fix(tg): ретраим весь TransportError, остальной RequestError → 502 без ретраев ... Follow-up к #3456. Тот PR научил три HTTP-ручки ловить общий `TelegramError` и отдавать 502, но закрыл дыру не до конца: клиент по-прежнему выпускал наружу сырой httpx. Ретраящийся `except` перехватывал узкий кортеж `(httpx.TimeoutException, httpx.NetworkError)`, а `RemoteProtocolError`, `ProxyError`, `LocalProtocolError` и `UnsupportedProtocol` — не наследники `NetworkError`, а сёстры по `TransportError`. Проверено запуском на httpx 0.28.1, не по памяти. Практическое следствие — ровно тот отказ, который #3456 и чинил. `RemoteProtocolError` («Server disconnected without sending a response») для api.telegram.org из РФ — бытовой ответ, а не экзотика. Он вылетал из `_request` сырым, проходил мимо `except TelegramError` в glitchtip.py:227 и support.py:233 и :424, и FastAPI снова отдавал 500. Глобального обработчика, который поймал бы его выше, нет: в `core/http_errors.py` зарегистрирован только `RequestValidationError`. Вдобавок такой отказ не ретраился ни разу — вылетал с первой попытки, без backoff и без строки лога о сетевом сбое, так что в проде отличить его от исчерпания бюджета было нечем. Теперь два `except`, и вместе они покрывают всё дерево отказов запроса. Ретраящийся расширен до `httpx.TransportError` — тело не тронуто, те же reason, backoff, лог и `TelegramNetworkError` из #3156. Ниже страховочный `httpx.RequestError` без ретраев: сегодня это `DecodingError`, завтра — всё, что httpx заведёт под `RequestError`. Порядок значим — `TransportError` наследник `RequestError` и обязан стоять выше, иначе сетевые отказы перестали бы ретраиться. Повторов у страховочного нет намеренно: испорченный ответ и кривую конфигурацию повтор не лечит, а пять попыток с backoff подвесили бы интерактивную ручку почти на минуту впустую. Расширение ретраев на `RemoteProtocolError` наследует уже принятый в этом клиенте риск at-least-once: запрос мог дойти до Telegram, а ответ потеряться. Риск тот же, что у давно ретраящегося `ReadTimeout`, политика не меняется. Прецедент лова именно `TransportError` в этом же репозитории — `app/services/payments/tbank_client.py:136`. Не тронуто: ручки (они уже ловят предок), `bridge.py` (`except TelegramApiError` там намеренный — разбор 403 «бот заблокирован»), `_extract_retry_after`, обработка 429/5xx, потолки backoff. Тесты: прежний тест «наружу свой тип» параметризован по `ConnectTimeout`, `RemoteProtocolError`, `ProxyError`, `DecodingError` с ожидаемым числом попыток; новый тест фиксирует разницу бюджета — обрыв протокола ретраится, битый ответ нет. Прогон по четырём затронутым файлам: 80 passed.	2026-09-12 09:19:42 +03:00
bot-backend	46326ba96e	fix(tg): недоступный Telegram отдаёт 502, а не 500 ... Прод 11.09.2026, 01:35 и 01:38 MSK — два 500 на glitchtip-webhook. Причина не в вебхуке: `TelegramClient._request` после исчерпания сетевых ретраев делал голый `raise`, наружу летел `httpx.ConnectTimeout`. Все три HTTP-ручки ловят `TelegramApiError` — сырой httpx пролетал мимо, и FastAPI отдавал 500 вместо задуманного 502. Отказ площадки и её недоступность для вызывающего неразличимы: переслать не смогли и там, и там. Клиент больше не выпускает наружу чужой тип. Появился общий предок `TelegramError`, под ним прежний `TelegramApiError` (ответили `ok: false`) и новый `TelegramNetworkError` (не ответили вовсе). Раздельно, а не наследником, потому что у сетевого отказа нет ни `error_code`, ни `description` — брать их неоткуда, а `bridge` по `error_code == 403` разбирает «бот заблокирован» и недоступность в этот разбор попадать не должна. Причина сохраняется в `__cause__`: в GlitchTip по-прежнему видно, таймаут это соединения или сброс TLS (#3156). Три ручки — вебхук GlitchTip и обе ручки поддержки, авторизованная и анонимная — ловят предок. Поведение воркеров не менялось: poll loop в `bridge` и так ловит `Exception`, бюджеты ретраев те же. Тесты: два в клиенте (свой тип наружу, причина не потеряна, это НЕ `TelegramApiError`), три на ручках (502 на недоступности, ничего не персистится, анонимной куки не выдаём). Четыре теста бюджета ретраев ждали `httpx.ConnectTimeout` — ждут новый тип, проверяемые паузы прежние. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-12 03:02:03 +03:00
bot-backend	1bcc922e80	fix(msk-collector): сетевой обрыв на машине больше не убивает многочасовой проход ... Полный проход Яндекса по Москве умер 12.09 на восьмом часу: `Page.goto: net::ERR_NETWORK_CHANGED`. Площадка была ни при чём — сразу после и realty.yandex.ru, и git.gendsgn.ru отвечали 200, а в ту же минуту по DNS отвалился и MCP-сервер ошибок. Моргнула сеть на самой машине. Ретрай в `_goto` ловил только `PlaywrightTimeoutError`, поэтому обычная сетевая ошибка уходила наверх и роняла прогон целиком. Сетевые отказы Chromium вынесены в `_TRANSIENT_NET_ERRORS` и считаются СВОИМ счётчиком: пять попыток с нарастающим ожиданием 15/30/45/60/120 с. Бюджет попыток по таймауту при этом не тратится — обрыв сети длится минуты, а таймаут навигации это совсем другой симптом. Исчерпали — стоп с причиной `nav_network`, прогон продолжается тем же batch-id с --resume. Всё, что не в списке, по-прежнему поднимается: тихий отказ площадки выглядит ровно так же, и молча проглоченный он превращается в пустой прогон. Тестов у сборщика не было вообще, при том что он уже дважды ронял многочасовой прогон на ошибке, которая отказом площадки не была. Заведён первый файл: он подгружает скрипт по пути (нет на месте — skip, не красный) и караулит границу «наше или ихнее» — распознавание сетевых ошибок, переживание короткого обрыва, остановка при длинном с правильной причиной, проброс незнакомой ошибки и неизменность прежнего пути по таймауту. Полный сьют бэкенда — 5902 passed, 37 skipped; ruff чист. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-12 02:35:42 +03: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	37494dd74a	fix(msk): тест полос по округам разъехался с main — у _fetch_deals нет rooms ... Post-merge прогон main после #3440 дал 5 failed: `_fetch_deals() got an unexpected keyword argument 'rooms'`. Семантический конфликт мержа, а не поломка: ветка отводилась до #3256, который УБРАЛ параметр `rooms` (сделки Росреестра комнатность не несут). Текстового конфликта git не увидел, pre-merge CI ветки был зелёным, красным стало только на объединённом дереве. В проде эффекта нет: `_fetch_deals` из `app/` не вызывается ни разу ни до, ни после мержа — функцию держат только эти тесты. `uv run python -m pytest tests/test_3051_moscow_okrug_bands.py` — 24 passed, ruff чист. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-12 01:53:33 +03:00
bot-backend	a99a9b870c	Merge pull request 'Москва: пред-геокод Авито, Яндекс третьей площадкой, продукт отвечает по региону 77' (#3440) from feat/msk-collector-cian into main	2026-09-11 22:30:11 +00:00
bot-backend	c4315b3dfb	Merge pull request 'fix(mera/estimate): убран предикат d.rooms в коридоре ДКП — он был вторым фильтром по площади (#3256)' (#3445) from fix/3256-asking-to-sold-buckets into main	2026-09-11 21:59:18 +00:00
bot-backend	6df6f92a2b	test(estimator): полоса площади — единственный фильтр похожести, а не просто «есть» ... `test_dkp_corridor_keeps_full_area_band` проверял только присутствие полосы ±15% в bind-параметрах — она есть и на origin/main, и на варианте с бакет-ключом, поэтому тест был зелёным по построению и ничего не охранял (мутационная проверка: при восстановлении предиката он оставался зелёным, пока остальные 4 краснели). Утверждение усилено до «полоса единственная»: тест дополнительно требует отсутствия предиката по rooms рядом с ней. На origin/main фильтров по площади ДВА (полоса и бакет через d.rooms), итоговое окно — их пересечение, поэтому теперь тест краснеет значением вместе с остальными. Refs #3256	2026-09-12 02:39:28 +05:00
bot-backend	16d99e0f1a	fix(estimator): убрать предикат по deals.rooms, а не подставлять в него area-бакет ... Разворот предыдущего коммита ветки (a780e3e6) на корень: вместо подстановки `area_bucket(area)` в предикат `d.rooms = ...` предикат УДАЛЁН во всех трёх местах. ПОЧЕМУ НЕ БАКЕТ. `deals.rooms` — синтетика из площади (321 559 из 321 560 сделок удовлетворяют `rooms == area_bucket(area_m2)`, max(rooms)=4), значит `d.rooms = X` тождественно `d.area_m2 ∈ [граница_X, граница_X+1)`. Это ВТОРОЙ, ступенчатый фильтр по площади поверх полосы `area_m2 BETWEEN :area_min AND :area_max`, стоящей строкой ниже. Прод-замер по 1179 реальным запросам (trade_in_estimates, 2026-09-12) — какая доля полосы ±15% переживает предикат: d.rooms = комнаты клиента медиана 77.8%, у 180 запросов полоса вырезана ЦЕЛИКОМ (пересечение пусто ⇒ коридора нет никогда) d.rooms = area_bucket(area) медиана 90.0%, пустых нет, НО у 902 из 1179 полоса всё ещё усечена: 44.0 м² → сохраняется 50% полосы, 62.0 м² → 50%, 82.6 м² → 59.7%. Величину усечения задаёт не модель, а случайное положение метража относительно границ 30/44/62/85. без предиката 100% по построению Т.е. бакет-ключ чинит катастрофический случай (пустое пересечение) и оставляет произвольное усечение у 76.5% запросов. Полоса ±15% уже выражает «похожие по площади сделки» — второго фильтра по тому же признаку быть не должно. ЗАМЕР ЭФФЕКТА НА ЦЕНУ (1179 запросов, все три пути влияния коридора на headline: cap/floor, sufficiency-гейт #oblast-E, deals-headline-fallback; листинговая сторона берётся из сохранённой оценки, коридор пересчитан на сегодняшнем снимке deals для всех вариантов, поэтому сравнение apples-to-apples; реплика сверена с ПРОДОВЫМ SQL на 58 оценках × 3 варианта — 174/174 совпадений): коридор доступен n>=3: 769 → 850 (бакет, +86/−5) → 874 (без ключа, +105/−0) n>=10: 567 → 623 (бакет, +66/−10) → 691 (без ключа, +126/−2) сдвиг headline vs текущий прод бакет без ключа клиентов сдвинулось 28 120 медиана сдвига +1.0% −1.6% p10 / p90 −30.6% / +6.1% −8.6% / +4.3% сдвиг > ±10% 10 (все вниз) 10 (7 вниз, 3 вверх) сдвиг > ±25% 4 2 по путям (медиана сдвига): бакет без ключа cap/floor, радиусная медиана +3.9% (p10 −36.3%) −1.7% (p10 −5.9%) cap/floor, якорь Tier C −10.1% (5 сдвигов, 4 из них >10% вниз) −0.8% sufficiency-гейт −0.4% +0.3% deals-fallback +3.5% (p10 −20.8%) −0.1% якорь Tier A 0 (коридор не влияет: cap exempt, floor требует anchor_tier is None) Вариант без ключа даёт больше покрытия (+105/−0 против +86/−5), сдвиг с медианой около нуля и БЕЗ кластера сильных падений, тогда как бакет-ключ несёт кластер Tier C с медианой −10.1%. Худший случай (−41.8%, Малышева 84, 1к/54 м²: премиальный лот прижимается cap'ом к коридору улицы) ОБЩИЙ для обоих вариантов — он появляется от самого факта наличия коридора, а не от выбора ключа. УТОЧНЕНИЕ ФАКТА ИЗ a780e3e6: «у 818 клиентов выборка не меняется» — неверно, их 793. Скрипт классифицировал через `min(max(rooms,0),4) == area_bucket`, из-за чего 27 клиентов с 5-6 комнатами попали в «совпадающие», хотя у них выборка меняется с пустой на непустую. (Практического прироста они всё равно не получают: их метраж 158-456 м² в основном вне окна импорта `area BETWEEN 18 AND 200`.) ЯКОРЬ ПРОТИВ МОЛЧАЛИВОГО ВОЗВРАТА. Ни один тест не краснел, если импортёр начнёт писать настоящую комнатность. tests/test_3256_deals_rooms_key.py теперь ПАРСИТ CASE из deploy/import-rosreestr.sh и сверяет его границы с `area_bucket()` (поточечно, на границах и между ними); у самого CASE стоит комментарий-якорь «поменяешь на реальную комнатность — вернись в #3256». Каверза (e) харнеса: формулировка «бакеты 0-2 чисты» УБРАНА как неверная. Замер по тому же пулу, который видит `_fetch_analogs` (свежесть 14 дней, вторичка, регион 66): совпадение rooms == area_bucket — бакет 0: 69.8%, 1: 63.5%, 2: 60.1%, 3: 54.6%, 4: 30.9%. В бакетах 0-3 модальная комнатность совпадает с бакетом, в бакете 4 — нет (мода 3, 54.5% пула). Добавлена перекрёстная ссылка: каверзы (d) и (e) СКЛАДЫВАЮТСЯ (неправильное МЕСТО + неправильный СЕГМЕНТ), а не спорят. Логи витрины `/street-deals` называли `rooms=%d` комнатностью клиента, хотя фильтра по ней в запросе уже нет — теперь печатают фактический ключ (полосу площади), а комнатность помечена как контекст запроса. НЕ входит в этот PR (заводится отдельно): TVF `street_sales_vs_listings` (data/sql/211_*.sql:89,113) — там асимметричный ключ (`d.rooms` синтетика, `l.rooms` настоящая), копипастой не чинится; каверза (e) для app/tasks/landing_showcase_deals.py:415/426. Refs #3256	2026-09-12 02:25:09 +05:00
bot-backend	ae6d28d5e2	fix(mera): pool_timeout 30→5 с — отдельным коммитом, с триггером отката ... Единственная правка ветки, которая меняет РЕЖИМ ОТКАЗА при исчерпании пула: было «медленно» (ждём коннект до 30 с), стало «быстро с ошибкой» (5 с и `sqlalchemy.exc.TimeoutError` → 500, глобального обработчика в app/main.py нет). И едет она во все сервисы образа — backend, scraper, tgbot (tradein-mvp/docker-compose.prod.yml), для скраппера и бота обоснования в коде нет: за 29 ч логов исчерпания пула не было ни разу, проверить новое значение на проде пока не на чем. Поэтому коммит последний в ветке: ветку можно мержить без него, а на проде — откатить одной командой (`git revert`). Обоснование самого значения: чекаут коннекта нельзя прервать `asyncio.wait_for`, он занимает поток `asyncio.to_thread` целиком, а пул потоков конечен (min(32, cpu+4)) — исчерпанный пул коннектов превращается в исчерпанный пул потоков. 5 с короче самого короткого бюджета источника (8 с Yandex/Cian/ house_meta; geocode 12 с, IMV 20 с — длиннее): занятый пул деградирует ОДИН источник, а не весь запрос. ТРИГГЕР ОТКАТА (вернуть 30 с) записан в комментарии рядом со значением: любое `QueuePool limit ... timed out` в логах бэкенда ЛИБО рост failed+zombie в `scrape_runs` после деплоя. Правка комментария по ревью (L2): «вчетверо больше любого бюджета внешнего источника (8 с)» было неточно — бюджеты 8 / 12 / 20 с, перечислены явно. Гейт `test_pool_checkout_wait_shorter_than_source_budget` переехал сюда же (в коммите без `pool_timeout` он был бы красным) и читает публичный `engine.pool.timeout()` вместо приватного `pool._timeout`. Refs #3083, #3408	2026-09-12 02:23:09 +05:00
bot-backend	cf71825c27	fix(mera): отмена по бюджету оставляла осиротевший поток в чужой Session ... Ревью PR #3444, M1. `_with_budget` — это `asyncio.wait_for`, а `asyncio.to_thread` отменить нельзя: снимается только ожидание со стороны loop'а. Корутина умирает, поток продолжает работать с ТОЙ ЖЕ `Session`, а вызывающий тем временем идёт дальше по своим шагам ПО ТОЙ ЖЕ сессии — следующий источник, `_fetch_anchor_comps`, `_persist_estimate_and_commit`. Два потока в одной сессии дают «another operation is in progress» / InvalidRequestError на следующем шаге БД: у источников её глушит `except` вокруг вызова, у персиста оценки не глушит ничего — 500 и потерянная оценка клиента, ровно под нагрузкой, ради которой PR и делается. `_db_step` теперь пробрасывает отмену ПОСЛЕ того, как поток отпустил сессию (`asyncio.shield` + ожидание шага). Цена — бюджет источника переезжает на длину ОДНОГО шага БД, а не на длину фетча, ради которой бюджет заведён. Почему не `threading.Lock` на сессию (вариант из ревью): лок внутри `_db_step` сериализует только шаги, которые через `_db_step` и проходят, — а названный пострадавший `_persist_estimate_and_commit` (estimator.py:5203) это ГОЛЫЙ `asyncio.to_thread(db...)`, как и ещё 17 мест эстиматора; лока они не берут, и дыра осталась бы открытой ровно там, где она стоит 500. Ожидание же в точке отмены закрывает ВСЕХ последующих потребителей сессии разом и не заводит глобального состояния (`WeakKeyDictionary`). Гейт по значению — tests/test_3408_db_step_cancel_orphan.py: следующий шаг (голый `to_thread`, как персист) не входит в сессию, пока сирота не закончил. Семантика проверена на питоне прода (3.12): `wait_for` по-прежнему отдаёт TimeoutError, источник деградирует в None. Остальное из ревью: - M2: комментарий у `_MAX_DEFERRED_REFRESH_TASKS` обещал за ОБА фоновых источника, а верен только для Яндекса. Циан держит коннект весь фетч (до 25 с): транзакцию открывают `_load_from_cache`/`load_session`, закрывает `db.commit()` в конце (scraper_kit .../cian/valuation.py:163,176,595). Формулировка сужена, остаток назван явно: функция общая со скраппером (cian_history_backfill.py:458), где коммит в середине менял бы семантику батча, — нужен отдельный опт-ин путь. На ПОТОЛОК пула остаток не влияет (коннект на задачу один независимо от того, как долго держится), только на среднюю занятость. - L1: `db.rollback()` после упавшего `_db_step` (estimator.py:1186) удалён — откат уже сделан в потоке, а на loop'е это блокирующий вызов. - L4: в core/db.py записано, что «пул >= суммы объявленных потолков» — ПОЛ, а не гарантия: коннект держит и любая ручка с `Depends(get_db)`, а глобального обработчика `sqlalchemy.exc.TimeoutError` в app/main.py нет (проверено: единственный handler — RequestValidationError, core/http_errors.py:59). - L3: гейт пула больше не читает `pool._timeout` и не молчит при переименовании `_max_overflow` — публичный `pool.size()` + приватное поле за явным assert'ом. `pool_timeout` из этого коммита УБРАН намеренно: это единственная правка, которая меняет режим отказа с «медленно» на «быстро с ошибкой», и она едет во все сервисы образа (backend, scraper, tgbot). Возвращается отдельным коммитом в конце ветки — чтобы ветку можно было смержить без него или откатить одной командой. Refs #3083, #3408	2026-09-12 02:20:26 +05:00
bot-backend	a780e3e66e	fix(estimator): ключевать сделки Росреестра area-бакетом, а не комнатностью клиента ... `deals.rooms` — не комнатность, а синтетика из площади: import-rosreestr.sh пишет тот же CASE 30/44/62/85, что `asking_to_sold_ratio.area_bucket`. Прод-замер 2026-09-11: 321 559 из 321 560 сделок удовлетворяют rooms == area_bucket(area_m2), max(rooms) = 4. Значит предикат `deals.rooms = <РЕАЛЬНЫЕ комнаты клиента>` — это переодетый фильтр по площади, который противоречит area-полосе ±15% рядом с ним, как только комнатность клиента нетипична для метража, и НИКОГДА не совпадает у клиентов с 5+ комнатами. Замер по 1177 реальным запросам (trade_in_estimates): ключ расходился с area-бакетом у 359 (30.5%); коридор ДКП пуст у 46.2% из них против 8.2% у совпадающих. По крупному жилью (≥85 м²): «3 комнаты» — 83.5% пустых коридоров, «5 комнат» и «6 комнат» — 100%, «4 комнаты» — 5%. Т.е. блок «реальные сделки» и клампы коридора (cap headline + radius-floor) молча выключались ровно у крупных лотов. Прогон тех же 1177 запросов через `_fetch_dkp_corridor` с обоими ключами: непустых коридоров 809 → 895, пригодных для клампа (n≥10) 567 → 623 (+66, −10), у 818 клиентов с совпадающей комнатностью выборка не меняется вовсе. Из 66 восстановленных коридоров 7 (5 из них ≥85 м²) обрезали бы headline вниз на медианных −10.1% — то есть сейчас часть крупных лотов оценивается выше, чем поддерживают реальные ДКП на той же улице. Правка — одно и то же во всех четырёх местах, где сделки фильтруются под клиента: `_fetch_dkp_corridor` (street + city-wide widen), `_fetch_deals` (радиус) и витрина `/street-deals`. Бэктест этим НЕ измеряется и в докстринг харнеса добавлена причина (каверза (e)): у всех 5500 сделок обеих прод-фикстур rooms == area_bucket, т.е. харнес кормит спайн синтетическим ключом и поэтому по построению не видит расхождения, которое в проде есть у 30.5% запросов. Refs #3256	2026-09-12 01:04:05 +05:00
bot-backend	9f696299de	fix(mera): sync-БД источников эстиматора — с event loop в поток и не через фетч ... Замер на проде 11.09 (изнутри хоста, тот же контейнер): - одна оценка 0.44 с (повтор адреса) / 0.97 с (новый адрес), из них БД 252/458 мс; - N=8 параллельных — все 200, heartbeat /health p95 5-7 мс, max 113-160 мс: loop сегодня НЕ голодает, «добавить воркеров uvicorn» замером не подтверждается (и умножило бы на N оба семафора, пять in-process лимитеров и пул); - зато одна фоновая догрузка Яндекса держала коннект пула 8.5 с (лиз прокси 33.856 → запись 42.334), а таких задач разрешено 8 при пуле 15. Правки: - estimator `_db_step`: SELECT/UPSERT кэша источников уходят в `asyncio.to_thread` и завершают транзакцию — коннект возвращается в пул ДО внешнего HTTP; - core/db: max_overflow 10→15 (потолок 20 на процесс ≥ 4+4+8 объявленных потолков одновременности) и pool_timeout 30→5 с (короче бюджета источника 8 с, иначе занятый пул съедает и бюджет запроса, и поток to_thread). Локальный замер ДО/ПОСЛЕ на тех же величинах: loop стоял 301 мс (0 тиков соседней корутины) → 0.2 мс (23.5k тиков); ожидание коннекта соседом во время фетча — таймаут пула → 0.1 мс. Refs #3083, #3408	2026-09-12 01:01:54 +05: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	50c1df5e0e	feat(msk): проба покрытия отвечает по Москве — сетка центроидов и радиус на точку ... Резолвер города в пробе покрытия знал только 9 центроидов Свердловской области, поэтому любой московский адрес получал not_covered с пустым городом при живой когорте рядом. Замер на проде: точка Тверской, 59 объявлений в радиусе 1 км, статус not_covered, город пустой; контроль по Екатеринбургу — ok. Москве заведена сетка из 67 центроидов, выведенная кластеризацией нашего же корпуса (35 552 объявления Циан, ST_ClusterKMeans), плюс 32 отрицательные точки Подмосковья: они участвуют в конкурсе ближайшего центроида, но порога не имеют, поэтому граница с областью проходит по конкурсу центров, а не по окружности. Радиус стал свойством центроида. У свердловских точек прежние 25 км байт-в-байт, у московских 8 км: круги плотной сетки складываются, и общий 25-километровый радиус протекал вглубь области — Наро-Фоминск 9.83 км до сетки, Кубинка 17.18, Чехов 22.25, все резолвились как «Москва». Порог Москвы жёлтый (12), не зелёный: 200 случайных московских адресов дают медиану когорты 14 и долю с когортой не меньше 12 равную 0.57, против 37 и 0.865 у Екатеринбурга. Остаточная цена — 48 московских объявлений из 35 552 (0.14%) в приграничной полосе выигрываются подмосковным центром. Тесты: 29 контрольных районов Москвы резолвятся в «Москва», 32 города области дают «город не определён», резолв по Свердловской области сверен с прежней реализацией на решётке из 851 узла — расхождений 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-11 01:37:27 +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	9898b6bc02	feat(tradein/geocoder): регион-параметризация геокодера — region_code в geocode()/known_city_hint, --region-code у скрипта сделок, region_code у admin geocode-missing (#3051) ... Геокодер был жёстко привязан к Свердловской области: viewbox 66 + bounded=1, accept только при state ~ 'свердловск' и точке в bbox 66, known_city_hint знал лишь города области → для 212 937 московских сделок (address 'Москва, <улица>') геокод давал None либо ложный хит по одноимённой улице области, а cache-ключ без города смешивал регионы. Теперь регион приходит от вызывающего (deals.region_code): viewbox и bbox из REGIONS[code], state-маркер per region ('свердловск'/'москва'), ЕКБ-тиры (geoportal/cadastral/local houses) только при 66, city-хинт через словарь региона → cache-ключ '|city=москва'. Дефолт 66 везде — для существующих вызовов поведение байт-идентично (ревью двумя линзами). Побочно: geocode-missing по умолчанию больше не берёт listings с region_code NULL (16 930 неактивных чужих городов, которые и раньше геокодились впустую).	2026-09-09 02:51:28 +03:00
bot-backend	beb487c12e	test(#3051): тесты трека «Москва» — импорт ДКП по 77, per-source чекпоинт, wildcard-хендлер, регион-скоуп ДКП-коридора, миграция 289, валидация deploy-скрипта ... Тесты пишутся ПОСЛЕ живой проверки функционала (правило от 08.09): импорт по 77 — run 6460 (212 937 строк), регион-фильтр коридора — smoke до/после импорта. 14 тестов: SQL-текст через inspect (regex \s+ для многострочных клозов), чистые функции, мок db по образцу 2846, subprocess bash с урезанным PATH (падение от валидации, не от отсутствия docker).	2026-09-09 02:23: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	fcf5887225	merge(#3051): main (#3421) в ветку импорта по региону — московская дельта поверх region_code/doc_type ... #3421 въехал в main параллельно с той же миграцией 288 (deals.doc_type, параметры region_code/doc_types). Разрешение: 288 — целиком версия main; наша дельта (FDW-колонки okato/quarter_cad_number/district, выключенный seed rosreestr_dkp_import_77) переехала в 289. scheduler.py — doc_types из main + canonical_city-маппинг/raw_payload/per-source чекпоинт. deploy-скрипт — валидация REGION_CODE и DOC_TYPE (интерполируются в SQL текстом).	2026-09-08 23:19:47 +03:00
bot-backend	1f24f12af9	chore(#3051): снять новые тесты до живой проверки; валидация REGION_CODE в deploy-скрипте ... Тесты трека «Москва» пишутся отдельным заходом после живого прогона импорта по 77 — правило проекта с 2026-09-08. Правки существующих тестов (bind-параметр вместо литерала 66, канонический source rosreestr_dkp_import_77) остаются. REGION_CODE в import-rosreestr.sh подставляется в SQL текстом — допускаем только целое.	2026-09-08 23:05:35 +03:00
bot-backend	84ee8e5990	feat(tradein/rosreestr): параметризовать импорт ДКП по региону, deals.doc_type (#3051) ... Трек 2 подготовки Mera к Москве. import_rosreestr_dkp принимает region_code из params (default 66 — байт-в-байт прежнее поведение), валидирует его через app.services.regions.REGIONS. Регион с canonical_city (77 — Москва, Росреестр отдаёт округ/поселение вместо города) подставляет city/address через одну SQL-ветку на bind-параметре :canonical_city, а не Python if/else на код региона; city IS NOT NULL не фильтруется для такого региона (иначе теряется ~10% строк), исходные city/okato/quarter_cad_number/district уходят в raw_payload. Чекпоинт курсора (_resume_dkp_cursor) стал per-region: source для поиска предыдущего прогона строится через _dkp_source_for_region (66 сохраняет легаси-имя 'rosreestr_dkp_import', остальные — суффикс кода) — иначе прогон по 77 либо никогда не резюмился бы (source-литерал не матчил), либо, при более наивном фиксе, унёс бы курсор чужого региона. product_handlers регистрирует wildcard rosreestr_dkp_import_* (по образцу deactivate_stale_*/avito_city_sweep_*), deploy/import-rosreestr.sh получил REGION_CODE env (bash-путь не region-generic — city-override только в Python). Migration 288: deals.doc_type + backfill 'ДКП' для source=rosreestr, foreign table gendesign_rosreestr_deals расширена okato/quarter_cad_number/district (проверено live на прод-БД), выключенный seed rosreestr_dkp_import_77.	2026-09-08 22:58:26 +03:00
bot-backend	476fb9b77a	chore(#3051): снять новые тесты — до живой проверки функционала тесты не пишем ... В существующем test_rosreestr_dedup_key оставлена только правка, без которой он падает после параметризации (литералы region_code=66 / doc_type='ДКП' ушли из SQL живого импорта). Новый тест-файл и добавленная функция сняты: поведение ещё не проверено на живом импорте, тест зафиксировал бы догадку.	2026-09-08 22:53:20 +03:00
bot-backend	cfe529fd14	feat(#3051): deals.doc_type + регион и тип документа как параметры импорта Росреестра ... ПОЧЕМУ: расширение на Москву упирается в два литерала. В источнике за 2024 по региону 77 лежат 30 627 ДДУ с медианой 112 743 против 107 005 ДКП с медианой 256 250 — это цены котлована, и без различимого признака в deals они развалят любую оценку. При этом тип сделки терялся при загрузке вовсе (в deals колонки не было), а фильтры region_code = 66 и doc_type = 'ДКП' стояли литералами в scheduler.import_rosreestr_dkp и в двойнике deploy/import-rosreestr.sh — сменить регион было нельзя, не правя код. ЧТО: - миграция 288: deals.doc_type text (idempotent) + бэкфилл 'ДКП' для source='rosreestr' (корректен, а не эвристика: всё загруженное прошло фильтр ДКП — и в импорте, и в 077) + явный region_code=66 в default_params расписания rosreestr_dkp_import вместо неявного дефолта в коде. Индекс НЕ добавлен: 2-3 значения, живые выборки идут по region_code/deal_date/geom — заведём частичный, когда появится режущий запрос; - import_rosreestr_dkp: region_code (default 66) и doc_types (default ['ДКП']) из params, фильтры через bind-параметры CAST(:region_code AS int) / ANY(CAST(:doc_types AS text[])), doc_type едет из SELECT в INSERT и в ON CONFLICT DO UPDATE. Дефолты сохраняют текущее прод-поведение байт-в-байт; - dedup_hash оставлен как 'ros:dkp:' || id: id уникален в источнике независимо от типа документа, а смена формы ключа осиротила бы уже загруженные строки (ровно то, что разгребала миграция 077); - deploy/import-rosreestr.sh: REGION_CODE / DOC_TYPE как env со старыми дефолтами, doc_type протащен через staging в deals; шапка про «ЕКБ квартиры» переписана честно — city-фильтр снят давно, скоуп = весь регион; - тесты: test_rosreestr_dedup_key переведён с ассертов на литералы на проверку «параметр + дефолт = скоуп 077»; новый test_3051_* проверяет bind-параметры реальным вызовом с моком Session, дефолты 66/['ДКП'], doc_type в колонках INSERT и текст 288.	2026-09-08 22:45:55 +03:00
bot-backend	f4d174283a	chore(#3197): cian-login — без холостой аренды и ложного отказа (/login сайдкара override не берёт); честные докстринги ... Code-review хвоста #3197: на `cian-login` аренда из пула не доходила до сайдкара. `BrowserFetcher._post_login` не кладёт `payload["proxy"]` (это делают только `fetch`/`fetch_json`), а на приёме `login_handler` (browser/server.py:2814-2817) зовёт `_no_live_proxy(provider, None)` и `_ensure_browser(provider)` без override — `/login` proxy-override не принимает вовсе. Lease брался в `__aenter__` и освобождался в `__aexit__` без пользы и без health-вердикта по узлу. Хуже холостого хода: при пустом пуле в production `_acquire_lease` поднимает `NoProxyAvailableError` ДО POST, `cian_auto_login` ловит любое `Exception` → `502 Browser login failed`. То есть единственная ручка ВОССТАНОВЛЕНИЯ cian-сессии отказывала ровно во время инцидента с пулом. Комментарий в admin.py при этом утверждал, что фикс закрывает InvalidIP на логине — неправда. Убран `proxy_provider=` (фабрика остаётся ради endpoint/environment из одного места). `use_pool` без провайдера фетчер игнорирует сам — `_acquire_lease`: `use_pool AND provider is not None` — поэтому ни аренды, ни прод-отказа. `domclick-detail-debug` не тронут: он ходит через `fetch`, где override реально кладётся в тело и читается сайдкаром — там #3197 остаётся настоящим фиксом. Тесты для cian обратные по значению и падают на HEAD ветки: `test_cian_auto_login_does_not_lease_from_pool` (провайдер не передан, `acquire` не вызван) и `test_cian_auto_login_survives_empty_pool_in_production` (пустой пул на проде не отдаёт 502). Стаб cian — подкласс настоящего `BrowserFetcher`, чтобы второе утверждение шло через реальный `_acquire_lease`, а не через заглушку. Follow-up (отдельной задачей): сайдкар `/login` не принимает proxy override → логин cian всегда с env-узла (сейчас выключенный узел 9).	2026-09-06 17:48:29 +05:00
bot-backend	8761602e9b	chore(tradein/proxy): последние две ручки admin.py — через фабрику фетчера; снят форс pool-режима у cian-history (#3197, #3386) ... Два хвоста одной темы — проводка пула прокси в контейнере backend. #3197: `cian-login` и `domclick-detail-debug` были последними прямыми конструкциями `BrowserFetcher(source=, endpoint=)` мимо `build_browser_fetcher`. Без `proxy_provider`/`use_pool`/`environment` сайдкар брал свой env-узел `SCRAPER_PROXY_URL` (на проде выключенный узел 9: 407 → camoufox `InvalidIP`), а прод-отказ «пул пуст» (#2616) на этих путях был мёртв — он смотрит на `environment`, который до конструктора не доезжал. Соседи по эпику уже переведены (#3382 cian, #3389 yandex). Прямых конструкций без провайдера вне тестов больше не осталось: остальные (backfill-задачи, pipeline) пул получают своими kwargs, а `endpoint=None`-ветки providers — это документированный `config=None` для офлайн-тестов. #3386: `_PoolCurlConfig` в `cian_price_history` форсил `use_proxy_pool_curl=True`, потому что у контейнера `backend` не было переменной. #3387 задал `USE_PROXY_POOL_CURL: "true"` сервису `backend` в compose — зашитая константа стала лишней и делала рубильник неотключаемым ровно на этом пути (докстринг при этом описывал уже неверную причину). Теперь `RealScraperConfig()` напрямую. Тесты меряют значения, а не наличие kwarg'а: на откате исходников красные 4 параметризации нового `test_3197_admin_debug_browser_pool_wiring` (`assert None is not None` — провайдер не передан) и `test_price_history_honours_flag_off` (`assert ['cian'] == []` — пул дёргался при выключенном флаге).	2026-09-06 17:22:46 +05:00
bot-backend	7d3c0eab51	fix(#3398): acurl_proxy_url — вторая отмена не бросает lease; тест меряет наш release, а не teardown; потолок бюджета в докстринге	2026-09-06 16:49:12 +05:00
bot-backend	e4feadefe6	fix(tradein/proxy): операции пула прокси уходят с event loop публичного /estimate (#3398) ... Вход в `providers/_proxy.py::curl_proxy_url` синхронный и стоял ДО первого await во всех трёх async-сайтах `/estimate` (avito/imv, yandex/valuation, cian/valuation). `RealProxyProvider.acquire/mark_health/release` ходят в БД синхронно (своя SessionLocal на операцию), а публичный backend крутится на ОДНОМ воркере uvicorn (#3083): на cache-miss это 3 источника x (acquire + mark_health + release) блокирующих вызовов прямо на loop'е. `_with_budget(asyncio.wait_for)` синхронный вход прервать не может, а при исчерпанном пуле коннектов (5+10) checkout ждёт до 30 с — весь инстанс молчит. `acurl_proxy_url` — async-обёртка над тем же синхронным контекстом: вход и выход через `asyncio.to_thread`, выход тоже (иначе mark_health/release держали бы loop на выходе). Семантика прежняя: `NoProxyAvailableError` до запроса, BaseException-ветка (#3397: отмена → health=False), release в finally. `to_thread` копирует contextvars, поэтому `current_run_id` (#3404) виден в потоке как раньше. Новое по сравнению с sync-путём: отмена может прийти ВО ВРЕМЯ acquire (раньше это было невозможно по построению). Вход держится через `asyncio.shield` и добирается в except — иначе выданная в потоке аренда висела бы до reap_stale_leases. Переключены только три сайта `/estimate`. Sync-вызывающие и async-сайты под scheduler (cian/detail.py::fetch_detail, cian/newbuilding.py::resolve_cian_zhk_url_via_search) остаются на `curl_proxy_url` — там loop не обслуживает публичные запросы.	2026-09-06 16:05:50 +05:00
bot-backend	75b0931fad	Merge pull request 'fix(cian): капча видна в отчёте прогона (ban_kinds.platform по типу) и банит узел на curl-пути (#3402 follow-up)' (#3406) from fix/3402-followups-ban-kinds-curl into main	2026-09-06 10:40:11 +00: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	f4099cb89a	Merge remote-tracking branch 'forgejo/main' into feat/3404-proxy-run-attribution	2026-09-06 13:05:38 +03:00
bot-backend	b89788ee99	feat(tradein/proxy): прогон знает свой узел, а снятый бан перестаёт стирать историю (#3404) ... Выбор оператора мобильного прокси опирался на две ненадёжные опоры. Первая: `scrape_runs` не знала, через какой узел шёл прогон — колонка `proxy_id` была только у банов и ротаций. «Какой узел собрал 5 карточек из 21» не выяснялось ни одним запросом. Вторая: `clear_source_bans` делала DELETE, а зовётся она после КАЖДОЙ успешной ротации exit-IP. У #540723 (МегаФон) 23 успешные ротации и ноль строк банов, у #540722 (Tele2) ротаций почти не было и 7 банов. «7 против 0» читалось как «Tele2 хуже», хотя в той же мере это «у МегаФона историю стёрли 23 раза». Теперь: - `scrape_runs.proxy_id` — последний выданный прогону узел; полная цепочка (если узел менялся mid-run) копится в `counters.proxy_ids`. Пишет `proxy_pool.attribute_run_proxy` из единственной точки — сразу после выдачи лиза в `acquire()`, поэтому curl-путь, браузерный sticky lease и ре-acquire при ротации покрыты одинаково. `run_id` доходит до адаптера через ContextVar (`scraper_kit.orchestration.run_context`): протокол `ProxyProvider.acquire` его не несёт, а `RealProxyProvider` живёт одним объектом на весь планировщик. Best-effort: `lock_timeout` 2с и проглоченное исключение — диагностика не вправе ронять выдачу прокси или ждать на блокировке строки прогона. - `clear_source_bans` гасит строку (`banned_until = now()`, `ban_count = 0`, `cleared_at`/`cleared_reason`) вместо удаления. Эскалация сохраняется 1:1: формула в `mark_banned` берёт ПРЕДЫДУЩИЙ `ban_count` показателем степени, при нуле это ровно `SOURCE_BAN_BASE_HOURS` — как после DELETE. Строка доживает до штатного purge по `SOURCE_BAN_PURGE_DAYS`. Для всех читателей `scrape_proxy_source_bans` погашенная строка неотличима от отсутствующей: acquire, оба guard-подзапроса `mark_banned`, `proxy_egress` (ранжирование по `ban_count` даёт 0, как у узла без истории), admin `_active_ban` — все гейтятся по `banned_until > now()`. Ничего не бэкфиллится: связать прошедшие прогоны с узлами нечем (`leased_by` исторически = NON_RUN_LEASE_MARKER), врать восстановленным значением нельзя. Миграция 287. Тесты: 9 новых на обе части (главный — эскалация после гашения даёт базовые 6ч, а не удвоенные) + 14 существующих переведены с DELETE-семантики на гашение, включая проверку, что секрет ротации не утекает в новое `cleared_reason`. Полный прогон бэкенда: 5600 passed, 37 skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011WHFxVPWoBnSZihkdH1Uou	2026-09-06 13:05:20 +03:00
bot-backend	957e9e8c01	fix(#3402): капча = «Captcha…» и «Вы не робот?» (бан+ротация); «Ошибка - Циан» — только лог на цикл наблюдения ... Ревью (⚠️ minor) на #3403: «Ошибка - Циан» может быть транзиентной 5xx-страницей, отданной с кодом 200, а не отказом конкретному узлу. Цена ошибки несимметрична — mark_banned эскалирует TTL до часов, поэтому 20-минутный сбой площадки выбил бы из выдачи весь пул. Один список маркеров этого различить не мог: и капча, и страница ошибки шли одним путём в BanPageDetectedError. Проба прода 06.09.2026 09:25 UTC (одна карточка по узлам через сайдкар): * узел 14, час назад отдававший «Captcha - база объявлений ЦИАН», вернул НАСТОЯЩУЮ карточку — капча снимается за 1-2 часа, то есть TTL бана по назначению; * узел 1 отдал ТРЕТИЙ вариант отказа — `<title>Вы не робот?`, 16 КБ (час назад — «Ошибка - Циан», 374 КБ). Прежние маркеры его не знали вовсе: отказ уезжал наверх как валидный HTML ровно так же, как до #3402. Маркеры разделены на два класса, одинаково в обоих слоях (образы backend и browser деплоятся раздельно и расходятся на часы): * КАПЧА — «captcha - база объявлений циан» + «вы не робот?»: безусловный отказ площадки, прежний путь (сайдкар → BanPageDetectedError → 403 + ban_page; kit → report_platform_ban + CianBlockedError). За ней нет контента, и узел, которому её показали, будет получать её дальше; * «ошибка - циан» — ТОЛЬКО ЛОГ: сайдкар отдаёт HTML клиенту как есть и пишет WARNING «страница ошибки Циана (title=…, upstream=…) — не бан, только лог (#3402)», kit при провале extract_state пишет WARNING и возвращает прежний None. Ни бана, ни рапорта, ни исключения — решение принимаем по частоте в логах за цикл наблюдения, а не по догадке о природе страницы. Нормализация заголовка прежняя (регистр/пробелы/тире). `_is_cian_refusal` → `_is_cian_captcha` + `_log_cian_error_page`; `_refusal_title` → `_page_title` и два кортежа маркеров рядом. Фальсификация: «вы не робот?» убран из маркеров обоих слоёв → kit 1 failed («DID NOT RAISE CianBlockedError»), сайдкар 3 failed («DID NOT RAISE BanPageDetectedError», `_is_cian_captcha` → assert False is True). Маркер возвращён, обе сьюты зелёные: backend 5599 passed / 35 skipped, browser 246 passed.	2026-09-06 14:55:45 +05:00
bot-backend	ff979d4afd	fix(tradein/cian): капча Циана с HTTP 200 — отказ площадки в обоих слоях (#3402) ... Циан отдаёт капчу (`<title>Captcha - база объявлений ЦИАН`, 44 КБ) и страницу ошибки (`<title>Ошибка - Циан`, 374 КБ) с кодом 200. Детектор сайдкара их не знал (_REFUSAL_STATUSES {403,429} + маркеры Авито/Домклика), HTML уезжал клиенту как успех, extract_state возвращал None и провайдер печатал «defaultState extraction failed» — отказ ПЛОЩАДКИ читался как дрейф НАШЕЙ разметки. Аренда при этом не менялась: fetch() уже отрапортовал mark_health(ok=True), fail-streak обнулялся, и один капча-узел сжигал батч целиком (6200: 0/210; 6123/6091/6052/6032/6010/5981: 0/400 — против 161/162 через здоровый узел на прогоне 13). Два слоя, потому что образы backend и browser деплоятся раздельно и расходятся на часы: * сайдкар (browser/server.py) — детект по <title> на обоих путях (navigate и подзапрос) → BanPageDetectedError → прежний путь #3288/#3379: 403 + ban_page + ЧЕСТНЫЙ upstream-статус 200; * kit (providers/cian/detail.py) — при провале extract_state те же маркеры → CianBlockedError вместо тихого None, плюс report_platform_ban по живому lease. Там же ветка SidecarBanPageError: отказ, опознанный сайдкаром, больше не гасится общим `except` в «не смогли разобрать». Слово `captcha` признаком быть не может: в нормальной карточке оно встречается 11 раз, на капче 17. Детект по <title> с нормализацией тире. `_report_platform_ban` → `report_platform_ban` (публичный): тем же путём обязан идти отказ, распознанный не сайдкаром, а провайдером. report_ban один только пишет бан пары «узел×источник» — сменить сожжённую аренду ВНУТРИ батча позволяет только fail-streak (_LEASE_ROTATE_AFTER_FAILS).	2026-09-06 14:10:57 +05:00
bot-backend	06ad504505	Merge pull request 'refactor(tradein): одна реализация scrape_runs — kit orchestration/runs.py, app-модуль = алиас; counters везде мержатся (#3390)' (#3400) from refactor/3390-single-runs-module into main	2026-09-06 08:11:52 +00:00
bot-backend	ae6ad9e440	docs(#3390): убрать ложные «counters ЗАМЕНЯЕТ» из комментариев/докстрингов; гейт test_3168 — честная формулировка	2026-09-06 12:34:53 +05:00
bot-backend	ec7838b7a9	fix(#3398): пустой пул в фоновой догрузке — WARNING без трейсбека (общая функция); комментарий про stateless ... На проде `ESTIMATE_EXTERNAL_SOURCES_BACKGROUND=true` (docker-compose.prod.yml:296), поэтому синхронный cian-вызов идёт с `fetch_on_miss=False` и возвращает None ДО прокси-слоя (`providers/cian/valuation.py:171`) — добавленная в этой ветке ветка WARNING в `estimate_quality` на проде почти не звучит. Настоящий фетч уходит в `_defer_external_refresh`, где `NoProxyAvailableError` попадал в общий `except Exception: logger.exception(...)` → ERROR + traceback → событие в GlitchTip на каждый /estimate по новому адресу: ровно тот шум, который PR и убирает. Правка в ОБЩЕЙ функции отложенной догрузки, а не в cian-ветке: через неё идут все источники фонового режима (yandex тоже — у него swallow живёт внутри `_get_or_fetch_yandex_valuation_cached`, дыры нет, но следующий источник получит поведение бесплатно). Для прочих исключений всё как было: `logger.exception`. Тест по значению: background=True + пустой пул в production → фоновая догрузка cian логирует WARNING «пул прокси пуст», записей ERROR/traceback у логгера эстиматора нет. Задача дожидается внутри того же loop'а и не снимая патчей (`_DEFERRED_REFRESH_TASKS` + `asyncio.gather`) — иначе `anyio.run` закрывает loop раньше старта задачи и тест был бы зелёным по построению. На HEAD ветки тест красный: ERROR app.services.estimator:estimator.py:910 deferred cian_valuation: догрузка не удалась (кэш не прогрет) + Traceback … NoProxyAvailableError. Комментарий у `_c_kwargs`: весь dict переиспользуется замыканием фоновой задачи, то есть `config`/`proxy_provider` — один инстанс на два возможно-одновременных вызова. Корректно ровно пока оба stateless (`RealScraperConfig` — read-only снимок настроек, `RealProxyProvider` без полей, короткая сессия БД на операцию); появится per-вызов состояние — фоновой задаче нужен свой инстанс.	2026-09-06 11:58:42 +05:00
bot-backend	36f2429fbe	refactor(tradein/runs): одна реализация scrape_runs — kit, семантика counters мерж (#3390) ... Две живые копии одного модуля с противоположной семантикой counters: app `mark_done`/`mark_failed`/`mark_banned`/`update_heartbeat` ЗАМЕНЯЛИ (`counters = CAST(:counters AS jsonb)`), kit — МЕРЖИЛИ (`COALESCE(counters,'{}') || …`). Расхождение дважды за сутки дало ложные выводы на ревью (#3388 «отдать только флаг, остальное домержится» — на replace это стёрло бы измеренное; #3355). Разошлись и другие места: гейт статуса, `honors_cancel` у mark_cancelled (был только в app), `mark_skipped` (только в kit), `mark_backfill_finished`/`distinct_sources` (только в app). Реализация теперь одна — `scraper_kit.orchestration.runs`; в неё перенесены app-only функции. `app.services.scrape_runs` — алиас kit-модуля через sys.modules, а не реэкспорт имён: реэкспорт разводит патч-цели (`patch("app.services.scrape_runs.sentry_sdk")`, `patch.object(runs_mod, "mark_done")` правили бы глобаль модуля-обёртки, а тело функции читает глобаль kit'а) — тест остался бы зелёным, не подменив ничего. С алиасом оба имени ведут в единственную реализацию, и ни один из ~40 вызывающих и ~30 патч-сайтов в тестах не правится. Победила семантика мержа: у строки прогона несколько писателей (пульс, финализатор, дрейн), каждый знает лишь свои ключи, и замена теряла чужие — чекпоинт done_buckets (#930), метку interrupted (#3391), замер из пульса (#3384). Обратной зависимости («вызывающий рассчитывает, что финализатор УДАЛИТ ключ заменой») нет: строка создаётся пустой в create_run, резюм читает counters ПРЕДЫДУЩЕГО прогона по его id. Тесты по значению на обоих путях импорта (двойник сессии читает SQL: `||` против CAST, WHERE-гейт из текста): пульс {a:5} + mark_failed {b:1} → {a,b}; пульс/финализатор по финализированной строке — no-op; mark_cancelled отказывает источнику, который отмену не опрашивает. На main эти тесты красные для app-пути. Комментарии в app/services/scheduler.py и kit/pipeline.py, утверждавшие про живого «перезаписывающего двойника», приведены в соответствие.	2026-09-06 11:45:56 +05:00
bot-backend	8a5f75d5f4	fix(tradein/estimator): yandex/cian valuation в /estimate через пул прокси, пустой пул не роняет ответ (#3398) ... Тот же корень, что у IMV (#3386 / PR #3397): оба вызова шли БЕЗ `proxy_provider` — `YandexValuationScraper(RealScraperConfig(), delay_provider=...)` и `estimate_via_cian_valuation(**_c_kwargs)`. `providers/_proxy.py::curl_proxy_url` считает `use_pool = флаг AND provider is not None`, поэтому пул был выключен по построению, а curl уходил на env-прокси SCRAPER_PROXY_URL (выключенный узел #2613): на проде 06.09 каждая проба `/estimate` давала `curl_cffi ProxyError: CONNECT tunnel failed, response 407`, а в логах это читалось как «yandex_valuation: empty result» — оба источника мертвы с 02.09. Kit-стороне правки не нужны: `YandexValuationScraper.__init__` и `estimate_via_cian_valuation` уже принимают kwarg-only `proxy_provider` и сами зовут `curl_proxy_url` (yandex — lease на сессию __aenter__/__aexit__, cian — lease на вызов, release в finally). Провайдер берётся из module-level импорта `RealProxyProvider` (он stateless: короткая сессия на операцию), поэтому один инстанс в `_c_kwargs` покрывает и основной вызов, и отложенную фоновую догрузку. Мягкая деградация сохранена и стала честной в логах: `NoProxyAvailableError` (проверка по цепочке причин `caused_by_no_proxy`) → WARNING «пул прокси пуст — продолжаем без Yandex/Cian» и прежний None-путь, а не ERROR «fetch failed» / «lookup failed» (запрос вообще не уходил — GlitchTip-событие тут было бы шумом). Строка «yandex_valuation: empty result» переписана: None неразличимо «дом не найден» и «фетч не дошёл», причина — в строке scraper_kit выше. Тесты (7, по значению; на main все красные): оба call site получают провайдера; пустой пул в production → оценка без этих источников, без исключения, HTTP не уходит, в логе «пул прокси пуст»; lease освобождён ровно один раз на успехе и на ошибке фетча — через настоящий `curl_proxy_url`, а не мок провайдера.	2026-09-06 11:30:28 +05:00
bot-backend	075cec4b57	Merge pull request 'fix(tradein/estimator): IMV-путь /estimate через пул прокси; пустой пул — честная деградация без IMV (#3386 п.в)' (#3397) from fix/3386-estimator-imv-proxy-pool into main	2026-09-06 06:04:07 +00:00