754 commits

Author	SHA1	Message	Date
lekss361	cef872ace1	Московская область в реестре регионов, обход — по специфичности вместо кода (#3501)	2026-09-12 13:59:43 +00:00
lekss361	ba2eb3b149	Merge pull request 'fix(tgbot): проверка темы при старте + общий rate limit на группу (#3471)' (#3494) from feat/3471-tg-topic-check-and-group-rate-limit into main	2026-09-12 13:37:09 +00:00
lekss361	3ed759da7d	Ряд Московской области в Сбериндексе — грузим заранее, до включения региона 50 (#3498)	2026-09-12 12:56:37 +00:00
bot-backend	acbfdf0a18	Merge remote-tracking branch 'forgejo/main' into feat/3471-tg-topic-check-and-group-rate-limit	2026-09-12 15:34:28 +03:00
bot-backend	8e7c65061b	fix(tgbot): honest H1 rejection, per-role H2 budget, M1/M2/L1 cleanup (#3471 review) ... Deep review of PR #3494 found the rate limiter unusable as designed: - H1: acquire() waited unbounded even for interactive HTTP handlers (support.py, glitchtip.py already pass a narrow `timeout` — reuse it as the queue wait cap instead of editing those handlers, which are out of scope here). New TelegramRateLimitedError (subclass of TelegramError) gives a fast, honest 502 instead of hanging past the caller's own budget. - H2: the limiter is per-process (in-memory), but two processes write to the same group (uvicorn API + bot worker) — giving each the same 18/min doubled the platform ceiling. Split into telegram_group_rate_limit_api_per_minute (12) and _bot_per_minute (6), sum kept below ~20. - M1: bridge.py sends without an explicit timeout inherited "wait forever", stalling the single-threaded poll loop (open DB session) past the SIGTERM drain window. Bounded via rate_limit_max_wait=20s at the six call sites. - M2: _locks/_sent_at grew unbounded on every unique DM chat_id. Added opportunistic cleanup of fully-expired entries. - L1: the "queue full" warning now logs once per acquire() call, not once per sleep iteration. - Corrected a factual error in the docstring: TELEGRAM_SUPPORT_CHAT_ID and TELEGRAM_ALERTS_CHAT_ID are the SAME group on prod (topics differ only). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JY6iWDnGDthdvsMWgK1BMG	2026-09-12 15:28:16 +03:00
bot-backend	d5c876e3d0	fix(tradein): включаем idempotency-key на фронте, чиним assert-crash и честность докстрингов (#3471) ... Ревью PR #3495 нашло, что механизм был мёртвым кодом: фронт не отправлял Idempotency-Key ни в одном запросе, весь прод-трафик шёл по ненадёжному fallback-отпечатку. Плюс два "assert" в record_inbound после ON CONFLICT давали AssertionError (не ловится except SQLAlchemyError) уже ПОСЛЕ доставки в Telegram — под `python -O` assert и вовсе исчезает. - useSupportChat.ts: useSendSupportMessage генерирует Idempotency-Key (crypto.randomUUID()) на намерение отправить, переиспользует его при повторной отправке ТОГО ЖЕ текста, сбрасывает на успехе. - web_support_storage.record_inbound: assert -> явные ветки с логом; логируем отброшенный topic_message_id проигравшего гонку (не молча). - Докстринги/комментарии переписаны честно: что именно закрывает pre-check (ответ клиенту потерян / двойной клик после успеха), а что НЕ закрывает (сетевую потерю на плече Selectel -> Telegram — там сообщение просто не доставлено, повтор это законная первая попытка). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JY6iWDnGDthdvsMWgK1BMG	2026-09-12 15:24:21 +03:00
bot-backend	6433477f7c	fix(tgbot): проверка темы при старте + общий rate limit на группу (#3471) ... Бот падал молча на каждом сообщении, если тему форума удалили/переименовали: узнавали об этом только по отсутствию сообщений у людей. tgbot_main теперь один раз на старте проверяет getChat + typing-индикатор с message_thread_id (единственный способ Bot API провалидировать message_thread_id без создания видимого сообщения) и громко пишет error при отказе, не роняя процесс. Второе: лимит Telegram (~20 msg/min) общий на всю группу, все темы делят бюджет — всплеск GlitchTip-алертов вместе с потоком поддержки в ту же группу уже давал 429 и терял сообщения. TelegramGroupRateLimiter — скользящее окно per-chat_id (НЕ per-теме) с asyncio.Lock на чат, встроен прямо в TelegramClient._request перед _post, поэтому считает все отправки независимо от relay/прямого пути и без изменений в support.py/glitchtip.py (они уже идут через общий клиент). Порог настраивается через TELEGRAM_GROUP_RATE_LIMIT_PER_MINUTE (дефолт 18, чуть ниже потолка площадки). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JY6iWDnGDthdvsMWgK1BMG	2026-09-12 14:59:54 +03:00
bot-backend	091befc9ff	fix(tradein): идемпотентная отправка сообщения в поддержку (#3471) ... Сеть Selectel -> api.telegram.org теряет заметную долю коротких запросов, поэтому браузерный ретрай/двойной клик/переотправка по таймауту при отправке в веб-чат поддержки создавали ВТОРУЮ строку в web_support_messages И второе зеркало в support-топике Telegram, а не только дубль в БД. Ключ идемпотентности (миграция 301, колонка idempotency_key + partial unique индекс (thread_id, idempotency_key) WHERE direction='in'): - явный заголовок Idempotency-Key от клиента, если он есть и валидной формы; - иначе детерминированный fallback-отпечаток sha256(identity|текст|минутное окно) — старые клиенты без заголовка продолжают работать без изменений. Pre-check резолвит тред по identity и ищет существующее inbound-сообщение с этим ключом ДО похода в Telegram (не только до записи в БД) — иначе повтор всё равно отправил бы второе зеркало, даже если бы вторая строка в БД не создавалась. Гонку двух одновременных запросов с одним ключом закрывает INSERT ... ON CONFLICT DO NOTHING на уникальном индексе в web_support_storage.record_inbound (не read-then-write), а не сам pre-check. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JY6iWDnGDthdvsMWgK1BMG	2026-09-12 14:59:52 +03:00
lekss361	994eb79323	Merge pull request 'Ожидаемые исходы скрапинга перестают быть ошибками' (#3488) from fix/3471-scraper-log-levels into main	2026-09-12 11:48:44 +00:00
lekss361	ede6fd5974	Merge pull request 'Продуктовый Telegram-трафик уходит через ретранслятор на Beget' (#3487) from feat/3471-telegram-relay-beget into main	2026-09-12 11:38:25 +00:00
bot-backend	70b1419cde	Merge remote-tracking branch 'forgejo/main' into fix/3471-scraper-log-levels	2026-09-12 14:36:08 +03:00
bot-backend	24c2052057	style(tg): перенос длинной строки заголовков ретранслятора ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JY6iWDnGDthdvsMWgK1BMG	2026-09-12 14:27:10 +03:00
lekss361	2edaae148f	Merge pull request 'Ответ оператора не исчезает при сбое БД, и реплай на собственный ответ снова маршрутизируется' (#3479) from fix/3471-bridge-db-failure-reply-loss into main	2026-09-12 11:26:29 +00:00
bot-backend	9a93e575cc	Merge remote-tracking branch 'forgejo/main' into feat/3471-telegram-relay-beget	2026-09-12 14:18:55 +03:00
lekss361	c826793a2a	Merge pull request 'Меньше шума: выключенные платежи не засоряют ленту ошибок, провал прокси-пробы пишется строкой вместо трейса' (#3483) from fix/3471-observability-noise into main	2026-09-12 11:18:33 +00:00
bot-backend	e0564d12fe	feat(tg): продуктовый Bot API трафик уходит через ретранслятор на Beget ... Замер 12.09.2026, оба хоста в одни и те же минуты: getMe из tradein-tgbot на Selectel — 9 успешных из 12, три ConnectTimeout; TCP-443 до адреса, резолвящегося на Selectel (149.154.167.220) — 5 из 6; TCP-443 до адреса, резолвящегося на Beget (149.154.166.110) — 8 из 8. За сутки в логе бота 508 строк network error, за 30 дней 92 обрыва итерации poll loop. Значит: путь до Telegram с Selectel лоссовый, с Beget чистый — Alertmanager (живёт на Beget) шлёт в тот же чат без проблем, а бот поддержки на Selectel часть отправок теряет. Добавлен ops/metrics/tg-relay — stdlib-only HTTP-сервис (тот же принцип, что у alert-ack: без зависимостей, поднимается даже когда всё остальное сломано), проксирует Bot API целиком (метод, путь, тело — sendMessage, copyMessage, getUpdates) на api.telegram.org. Токен из пути не логируется: log_request переопределён полностью, путь редактируется до записи в лог. Аутентификация — общий секрет в X-Relay-Secret, по образцу X-Internal-Auth-Secret из этого же стека. Клиент (tgbot/client.py) при транспортном отказе похода на ретранслятор делает одну попытку напрямую к api.telegram.org — хуже прямого пути быть не должно ни при каких условиях. Пустой TELEGRAM_RELAY_BASE_URL — прежнее поведение без изменений, это и есть механизм отката. Refs #3471	2026-09-12 14:16:05 +03:00
bot-backend	ac5b044f7e	fix(scrapers): ожидаемые исходы сбора (бан, пустой пул, капча) больше не error ... Скрапер один давал 3006 error-строк в сутки из ~3700 по всему Trade-In — ленту перестали читать, и настоящая поломка терялась в ней. Принцип: ожидаемый исход сбора (площадка забанила, пул прокси пуст, капча/недогруз, серия блоков перевалила порог circuit breaker) — это состояние работы против недружелюбного источника, а не инцидент. В error остаётся только неожиданное: изменившаяся вёрстка/схема (Cian markup change), просроченный токен ротации прокси (ASocks 401), неразобранное исключение. Переведено error -> warning в 9 файлах, 12 мест: "СТОП — пул прокси пуст" (avito/domclick/cian_history/yandex_newbuilding_sweep x2), "пул прокси исчерпан" (cian_session, cian_price_history, yandex_address_backfill), FAIL-CLOSED без здорового узла для source (proxy_egress), ABORT по счётчику подтверждённых блоков площадки (avito, domclick, yandex_detail_backfill). Оставлено error намеренно: cookie-алерты Cian/DomClick (#2658, #2674) — они рассчитаны именно на LoggingIntegration(event_level=ERROR) в scheduler_main.py и без него молчат по 37 дней; ABORT по смешанным/soft причинам без единого подтверждённого блока площадки (#3272, #2674/#3196) — это может быть наш баг, а не бан, сигнал сознательно не приглушали. GlitchTip: сентри-интеграция скрапера уже настроена как LoggingIntegration(level=INFO, event_level=ERROR) в scheduler_main.py — отдельной правки sentry_scrub.py не требуется, понижение уровня logger само убирает эти записи из GlitchTip. Итоговая FINISHED-строка со счётчиками (attempted/enriched/blocked/failed) уже существует в каждом detail_backfill — новую не добавлял. Refs #3471	2026-09-12 14:15:59 +03:00
bot-backend	5e80b56bdc	fix(tg): out-строки писались с support_chat_id=NULL — вечный wildcard-матч ... Deep review PR #3479 нашёл дефект в предыдущем фиксе (#3471 пункт 3): новые direction='out' строки стали видимы резолверам (find_chat_by_topic_message, find_thread_by_topic_message), но писались без support_chat_id. Резолверы матчат support_chat_id IS NULL как лениентный wildcard "любой текущий чат" (легаси-строки до 187/188) — то есть КАЖДАЯ out-строка становилась таким wildcard. При ротации support-группы новый message_id мог бы случайно совпасть со старой out-строкой: TG-путь увёл бы ответ ЧУЖОМУ клиенту через copyMessage, веб-путь записал бы ответ в чужой тред. Ровно от этого защищали миграции 187/188 (review M1). - bridge.py: TG- и веб-ветка `_handle_group_reply` теперь передают support_chat_id=settings.telegram_support_chat_id в record_message / record_web_out_message (симметрично уже существующей in-ветке). - web_support_storage.record_outbound: добавлен параметр support_chat_id, пишется в INSERT (колонка уже существовала, DDL не нужен). - Тест test_group_reply_to_own_previous_tg_reply_resolves_target_chat сидел предыдущую out-строку с уже заполненным support_chat_id вручную, хотя код писал NULL — маскировал дефект. Добавлены прямые проверки на записанное support_chat_id (TG и веб), обе падают на прежней реализации (проверено локальным откатом изменения — 2 failed, restore — 41 passed). - Комментарий про "апдейт частично применён в Telegram" в except-ветке веб-ответа был неверен для этого случая (на веб-пути ничего не уходит в Telegram до сбоя БД) — переписан на настоящую причину: сбой БД не переигрывается по общей политике process_update, а не из-за частичной доставки. Refs #3471	2026-09-12 14:15:57 +03:00
bot-backend	165c4a5edd	fix(obs): убрать шум выключенных платежей и трейсы health-проб proxy_pool ... Два источника шума в error-ленте и логах: 1. GlitchTip группа TRADE-IN-3GG: 167 событий за 29.08-12.09 — 503 "payments are disabled" из payments.py._require_enabled, которые бьёт внутренний IP смоук-проверки (кнопки оплаты во фронте нет). sentry_sdk StarletteIntegration репортит любой HTTPException с кодом из 5xx как error-событие, даже когда FastAPI штатно обработал исключение и вернул корректный ответ. Добавлен before_send-фильтр drop_payments_disabled_event (app/observability/sentry_scrub.py), матчащий по (status_code=503, detail="payments are disabled") через hint["exc_info"] — не по коду 503 в целом, чтобы не проглотить другие 503. Подключён во всех трёх точках инициализации sentry_sdk.init (app/main.py — единственный реальный источник события, scheduler_main.py и tgbot_main.py — belt-and-suspenders для единообразия, по образцу scrub_payment_request_body). Само поведение ручки не меняется — 503 остаётся, фильтруется только репортинг в трекер. 2. proxy_pool._probe_proxy: httpx.ProxyError (407 от прокси-провайдера) не попадал ни под TimeoutException, ни под ConnectError и падал в generic except Exception с exc_info=True — 184 строки полного traceback в сутки на штатный провал health-пробы, хотя итоговая сводка checked/ok/failed и так его учитывает. Добавлена отдельная ветка except httpx.ProxyError с логом в одну строку (узел + причина текстом исключения, без трейса). Логика самой пробы, аренды узлов и правил пула не изменена. Тесты: tests/test_sentry_scrub.py (drop_payments_disabled_event — дропает целевой 503, пропускает прочие ошибки и прочие 503/detail-комбинации), tests/services/test_proxy_pool.py (ProxyError логируется одной строкой без exc_info, счётчики healthcheck не ломаются). Refs #3471	2026-09-12 14:03:39 +03:00
bot-backend	99f123e646	fix(tg): ответ оператора на веб-чат не теряется молча при сбое БД ... Для веб-треда запись в web_support_messages(direction='out') И ЕСТЬ доставка клиенту (веб-фронт читает её polling'ом). process_update на SQLAlchemyError безусловно делал rollback() и всё равно сдвигал offset — Telegram апдейт больше не отдавал, ответ оператора пропадал навсегда, а сам оператор был уверен, что ответил. Воспроизведено на проде 31.08.2026 (клиент kopylov). - `_handle_group_reply`: сбой БД на `record_web_out_message` теперь ловится локально — rollback → уведомление оператору реплаем в топик, что ответ НЕ доставлен и его нужно повторить; offset всё равно сдвигается (апдейт уже частично применён в Telegram, переигрывать нельзя). - `_notify_topic` возвращает bool: если само уведомление тоже упало (Telegram недоступен), пишем `logger.error` с thread_id/message_id (без текста переписки — ПДн в лог не идёт), чтобы это не осталось полностью немым. - Второй дефект того же узла: `direction='out'`-строки никогда не сохраняли topic_message_id, из-за чего реплай оператора на СВОЙ предыдущий ответ не резолвился (маршрут держался только на зеркале клиента). Теперь TG- и веб-путь сохраняют id ответа оператора в топике, `find_chat_by_topic_message` / `find_thread_by_topic_message` больше не фильтруют по direction. Колонка и partial unique индекс уже существовали (186/187) — миграция не потребовалась. Refs #3471	2026-09-12 13:59:52 +03:00
bot-backend	d78b1f8881	fix(tradein): ДКП-коридор по Москве не строился — имя улицы не извлекалось ... `extract_street_name` возвращал None для любого московского адреса, потому что парсер ждёт тип улицы ПЕРЕД названием («ул. Малышева»), а в Москве он стоит после: «Тверская улица, 6». Keyword-регекс требует пробел сразу за типом, там запятая — совпадения нет вовсе; дальше fallback брал первый токен с большой буквы, получал «Москва» из стоп-списка и отдавал None. Следствие на проде (замер 12.09): оценка по московскому адресу отвечает 200 с 25 аналогами, но `dkp_corridor` в ответе — null, при 212 937 московских ДКП в базе. Коридор сделок по Москве не строился ни разу. Добавлен второй проход: ищем тип улицы без требования пробела и берём 1-3 слова ДО него в пределах той же запятой-секции. Прежний путь не тронут — «ул. X» и реверс-формат Nominatim разбираются как раньше; непустые результаты не меняются, новый проход даёт значение только там, где раньше был None. Списки типов улиц вынесены в общую константу, чтобы два регекса не разъехались при добавлении нового типа. Нумерованные проезды («Проектируемый проезд № 4062») намеренно остаются None: имя «Проектируемый» собрало бы коридор по сотням разных проездов. ## Регион-скоуп двух ручек Непустое имя улицы включает `/street-deals` и `/sales-vs-listings`, где раньше для Москвы был ранний выход. Обе скоупятся только по `_resolve_target_city` — словарю городов Свердловской области, — поэтому для Москвы фильтр города пуст, и остаётся один ILIKE по улице. Замер на проде: улица «Ясная» — 168 сделок в регионе 66 и 80 в 77, «Советская» — 1202 и 17. Без фильтра региона московский запрос смешал бы екатеринбургские сделки в медиану, то есть фикс парсера сам по себе открыл бы дыру. Поэтому в обе ручки добавлен обязательный фильтр по `region_code`; регион выводится из адреса через реестр регионов точным сравнением сегмента, а не подстрокой — иначе екатеринбургская «Московская улица» уехала бы в регион 77. В `deals` регион заполнен у всех строк (66 → 108 623, 77 → 212 937, NULL нет), так что фильтр ничего не отрезает у существующих запросов. У `/sales-vs-listings` табличная функция параметра региона не знает, её миграция в этот фикс не входит. Фильтр применён снаружи, соединением с `deals` по идентификатору сделки: сторона объявлений остаётся без регион-скоупа. Это осознанный компромисс, он описан в коде; полный фикс — отдельная миграция с параметром региона внутри функции. Тесты: 535 passed во всех файлах, затрагивающих коридор и уличную статистику (+13 новых), ruff чистый.	2026-09-12 13:43:56 +03:00
bot-backend	03d9745b4f	Отмена по бюджету больше не оставляет поток в сессии запроса — оценка не теряется на 500 (#3449)	2026-09-12 10:11:19 +00:00
bot-backend	668ac40631	fix(tradein): подпись коридора говорит про выборку, а не про алгоритм ... Ревью #3462 поймало ложь в микрокопии: «оценку по ним не корректировали» утверждает про АЛГОРИТМ то, чего код не гарантирует. Порог estimate_corridor_clamp_min_n гейтит только две страховки — кламп headline и radius-floor. Третий ценовой путь, гейт Tier C (#1795 шаг 3, estimator.py), сравнивает якорь с потолком коридора БЕЗ порога вообще: коридор из пяти сделок там способен уронить headline на треть (воспроизведено ревьюером: якорь Tier C 300 000 ₽/м², с коридором 200 000 против 300 500 без него). Плюс deals-headline-fallback берёт медиану коридора начиная с трёх сделок. Формулировка переписана на утверждение о ДАННЫХ — оно истинно во всех достижимых состояниях: «справочно: сделок мало (N) — коридор ориентировочный». Ветка «объявлений рядом нет» (n_analogs = 0) больше не молчит: раньше там возвращался null, и клиент не узнавал, что вся его цена стоит на трёх сделках. Теперь — «оценка построена на этих сделках — их всего N». Докстринги advisory_only в схеме и комментарий у лога тоже перестали обещать «коридор в цену не пошёл»: поле значит ровно «страховки выключены». Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 14:36:29 +05:00
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	b71f3f9957	fix(tradein): коридор ДКП с малым числом сделок помечен справочным ... Показ коридора открывается с трёх сделок (DKP_CORRIDOR_CITY_WIDE_MIN_N), а обе ценовые страховки по нему — soft-кламп headline сверху и radius-floor снизу — включаются с десяти (estimate_corridor_clamp_min_n). В зоне n=3..9 коридор существует, показывается и участвует в fallback-путях, но цену не держит, и на экране это неотличимо от работающего коридора. PR #3445 (снятие предиката d.rooms) переносит туда реальных клиентов: замерено 248 → 3 и 72 → 8 сделок. Решение — advisory-only. Порог показа не поднят (это отняло бы у клиента информацию), кламп по трём сделкам не включён (был бы хуже своего отсутствия), но зона теперь названа вслух: - DkpCorridor.advisory_only — computed-поле от count и ЕДИНСТВЕННОГО порога estimate_corridor_clamp_min_n, так что верно во всех конструкторах коридора (POST /estimate и GET-rehydrate) и не дублирует порог вторым числом; - лог INFO с маркером corridor_advisory_zone (n, порог, scope street/city_wide, id оценки) — одна строка на оценку, считается за сутки одним grep -c; - _fetch_dkp_corridor отдаёт служебный ключ scope: «мало сделок на улице» и «мало сделок во всём городе» — разные новости, и лог обязан их различать; - на экране (v1 hero + плитка ДКП в v2) подпись «справочно: мало сделок — оценку по ним не корректировали». Подпись молчит, когда headline ПОСТРОЕН из этого же коридора (n_analogs = 0, deals-fallback): там показанная цена и есть медиана этих сделок, и подпись была бы ложью в другую сторону. Тесты по значению (test_3452_corridor_advisory_zone.py) гоняют настоящий estimate_quality с коридором, потолок которого заведомо ниже медианы аналогов: в зоне headline НЕ прижат и метка стоит, выше порога — прижат к cap и метки нет. Захардкоженный флаг в любую сторону и снятый порог клампа роняют тесты (проверено руками). Closes #3452 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 13:42:43 +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	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	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	86cba37218	docs(#3256): докстринг коридора без «та же rooms»; якорь называет оставшегося потребителя (TVF 211)	2026-09-12 02:53:03 +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	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	996b814919	feat(msk): пред-геокод московского Авито — город из слага, регион из КЛАДР ... У карточек Авито нет координат ни у одной из 50 335, а адрес — голая улица с домом («Варшавское ш.,62к1»). Сбор шёл по `/moskva_i_mo/`, поэтому Москву от области отделить было нечем: префиксный фильтр, работающий у Циана по округу, здесь отбросил бы 100% строк. Наивный матч адресов к `houses(77)` даёт ровно 0 совпадений — дома лежат как «ЮАО, р-н Даниловский, проспект Андропова, 18». Замер показал, что одного геокода мало: с констрейнтом «Москва + Московская» дом находится у 92% адресов, но верхний кандидат DaData расходится с реальным городом у 15% и почти всегда в пользу столицы. Недостающий сигнал лежал рядом и бесплатно — слаг города в `source_url` (`avito.ru/moskva/...`), заполнен у 100% карточек: 22 120 с `moskva`, остальное — подмосковные слаги. Поэтому город берётся из слага и сужает констрейнт, а регион — из КЛАДР ответа, не из слага: Новая Москва (Троицк, Щербинка, Коммунарка, Зеленоград) идёт своими слагами, но это регион 77. Регион 77 пишется в `listings` сразу с координатами и `geo_precision='house'`, поэтому строки попадают в radius-подбор аналогов без ожидания `geocode_missing`. Регион 50 не пишется, а копится строкой в кэше `msk_raw.avito_geocode` — до появления региона в реестре. Кэш ключуется слагом и нормализованным адресом, отрицательные ответы тоже кэшируются, так что повторный прогон внешний сервис не дёргает. `geocode_cache` приложения не тронут — там другой ключ. `--allow-unfiltered` без `--geocode` остаётся прежним аварийным режимом. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-11 18:16:18 +03:00
bot-backend	491f7d43ac	feat(msk): полосы цен по округам Москвы и СберИндекс по региону запроса ... ПОЛОСЫ. deal_city_price_bands ключевались парой (region_code, city), а у всех 212 937 московских сделок city равен «Москва» — одна полоса 34221..718870 на весь город при четырёхкратном разбросе цены между округами. Ключом стало выражение COALESCE(NULLIF(raw_payload->>'src_city',''), city): округ заполнен у 198 600 сделок (93.27%), 197 различных значений. Выражение живёт в одном модуле app/services/deal_city_key.py и используется и derivation, и всеми тремя читающими местами — разъехавшийся ключ означал бы мёртвые строки таблицы. Поиск полосы двухступенчатый: строка округа, затем строка города, затем глобальные константы. Без второй ступени окно между деплоем и первым ночным рефрешем уронило бы московские сделки на калибровку Екатеринбурга (пол 50 000 против 34 221). Замерено на проде: двухступенчатый поиск оставляет 208 677 сделок из 212 937, одноступенчатый — 207 594. Потолок полосы стал региональным и собирается из именованных констант, общих у SQL и питоновского двойника: GREATEST(800000, LEAST(p99.99, 6 x медиана)). Регион 66 получает те же 800 000, регион 77 — 1 766 742, поэтому дорогие округа (Пресненский p99 = 1 198 694) больше не срезаются потолком. СБЕРИНДЕКС. Временная поправка замороженных ДКП-сделок была прибита к ряду «Свердловская область» и применялась в том числе к московским сделкам. Замер: средневзвешенный по 69 138 московским сделкам за 12 месяцев фактор равен 1.0313 по свердловскому ряду против 1.0917 по московскому — коридор занижен на 5.9%, и он не advisory: участвует в clamp headline, radius-floor и Tier-C gate. Ряд теперь резолвится по региону запроса, регион вне карты получает общероссийский ряд, а не чужой региональный. Монитор свежести следит за обоими рядами. Пропажа чужого ряда больше не подавляет вердикт по ряду региона по умолчанию, ошибка драйвера откатывает сессию, счётчики заполняются и в ветке раннего выхода. РЕГИОН 66 БАЙТ-В-БАЙТ. src_city пуст у всех 108 623 его сделок, поэтому обе ступени ключа совпадают; популяция derivation и все 383 строки полос не изменились, потолок остался 800 000, ряд СберИндекса тот же. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-11 01:37:48 +03:00
bot-backend	b1727ca39c	feat(msk): импорт сырья по Москве в listings и region-aware геокодирование ... Три куска, каждый нужен, чтобы поиск и оценка по Москве заработали end-to-end. 1. Импортёр msk_raw -> listings (app/tasks/msk_raw_import.py). Переиспользует штатный save_listings из кита: писатель уже параметризован регионом, свой не нужен. payload в msk_raw — сериализованный ScrapedLot один в один, так что импорт сводится к сборке модели и вызову писателя. Москва отбирается по префиксу административного округа в адресе, а не по bbox. Причина: адрес Циан не содержит города, а границы региона 77 захватывают ближний пояс области. Замер по проду: с округом 35 552, все внутри bbox 77; без округа внутри bbox 17 576 — это область. Отдельно отсекаются 212 карточек с адресом «Екатеринбург (Cian)», артефакт парсера. listing_segment ПЕРЕСЧИТЫВАЕТСЯ перед записью, а не копируется из payload. Кит ставит novostroyki по одному наличию offer.newbuilding.id. Замер по всем 60 464 карточкам: is_from_developer=true у НУЛЯ, false у 29 000, отсутствует у 31 464. Застройщик не продаёт ни одной карточки корпуса. В проде есть гвард (estimator.py): в аналоги идут строки только с listing_segment IS NULL или 'vtorichka' — копирование метки как есть выбросило бы 29 000 строк из подбора. Авито импортируется только с явным --allow-unfiltered: в его адресе нет ни города, ни округа, координат нет ни у одной из 50 335 карточек, отличить область от Москвы нечем. Прогон на проде: прочитано 60 464, записано 35 552, все с геометрией, 35 182 привязаны к дому, создано 10 960 домов. Повторный проход строки не дублирует — idempotency на dedup_hash, проверено. 2. Подсказки адреса стали региональными (geocoder.suggest, api/v1/geocode). Раньше suggest вообще не принимал регион: DaData звалась с жёстким region='Свердловская', Nominatim — с viewbox 66-го и bounded=1. Московский адрес давал ПУСТОЙ список молча, без ошибки; в коде это уже было описано как известный баг. Механику по регионам переиспользовали из geocode(), вторую не писали. Кадастровый тир для не-66 не зовётся: он на ЕКБ-данных. 3. Оценка перестала геокодировать Москву свердловским скоупом (estimator). geocode() звалась без региона, то есть с дефолтом 66, и московский адрес возвращал бы пустую оценку с причиной address_not_geocoded даже с рабочими подсказками. Регион запроса определяется по координатам через реестр, затем по city_hint, затем дефолт. Fast-path клиентских координат стал региононезависимым: OBLAST66_BBOX и REGIONS[66].bbox_region совпадают байт-в-байт, поэтому для 66 поведение прежнее, добавились координаты Москвы. Регресс-нейтральность по Свердловской области — главный критерий всех трёх кусков. Тесты: 1160 passed по затронутым областям. Известные ограничения. Границы 77 захватывают ближний пояс области, Химки резолвятся в Москву. У региона 77 нет ни одного тира обогащения, оценка поедет на аналогах и сделках. Ценовая полоса по Москве одна на весь город. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ8jqr4SFirX5tFLwdSrXh	2026-09-10 18:50:37 +03:00
bot-backend	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	1d9adb4a24	feat(tradein/estimator): deal_city_price_bands по ключу (region_code, city) — миграция 298, refresh per-region, потребители (#3051 sub-PR B) ... После импорта 212 937 московских ДКП (region_code=77) region_stats refresh'а (p1 для tier region_fallback) считался бы по пулу 66+77 и поднял бы floor ~250 малым городам области. Ключ bands становится (region_code, city): миграция 298 (колонка DEFAULT 66, смена PK через DO-guard, re-seed per-region, ЕКБ-исключение только для 66, doc_type=ДКП), тот же SQL в refresh-джобе, estimator/backtest читают bands по паре. Для 66 набор строк байт-идентичен прежнему (ревью двумя линзами).	2026-09-09 02:25:47 +03:00
lekss361	e0bef636e6	feat(tradein): bulk-дампы открытых данных ФНС по юрлицам + lookup по ИНН (#3429)	2026-09-08 22:29:10 +00:00
lekss361	50f0674977	feat(tradein): слой ДТП из dtp-stat.ru в PostGIS + радиусные агрегаты (#3428)	2026-09-08 22:10:56 +00:00
bot-backend	1f3566c466	merge main в feat/mera-cbr-macro — оба handler'а (frt_mkd_load + cbr_macro_pull) в реестре	2026-09-09 00:43:13 +03:00
bot-backend	2abab8218e	feat(mera): макро-ряды ЦБ РФ — ипотека по субъектам и ключевая ставка ... Три XLSX ЦБ (выдачи, ставка, задолженность) в разрезе субъектов, помесячно с 01.2019, + ключевая ставка через SOAP DailyInfo.asmx (метод KeyRate; GET на нём не работает, только POST). Всё анонимно, без ключа. Таблицы: cbr_mortgage_series (region, period_month, series) и cbr_key_rate. fetched_at НЕ обновляется в DO UPDATE — по уроку #2846 колонка значит «когда мы ВПЕРВЫЕ увидели период» и по ней меряется такт публикации источника. Раскладка листов у ЦБ РАЗНАЯ, и это ловушка: в 02_11/02_13 шапка периодов в строке 3 текстом («Январь 2019»), а в 02_14 (задолженность) — уже в строке 2 и настоящими datetime. С захардкоженным индексом строки серия debt_rub молча давала НОЛЬ строк при зелёных тестах. Теперь строка шапки ищется динамически: берётся строка с наибольшим числом распознанных периодов среди первых шести. Проверено на живых файлах: каждая из трёх серий даёт 8 736 точек (96 территорий × 91 месяц, 01.2019–07.2026); по Свердловской области 91 месяц, последняя ставка 11.49. estimator.py не тронут: как ипотечная ставка войдёт в оценку — отдельное продуктовое решение, этот PR только про данные. Миграции 292 (таблицы) и 293 (сид расписания, enabled=false, interval_days 7). Новая зависимость: openpyxl.	2026-09-09 00:33:12 +03:00
bot-backend	8aca820a46	feat(mera): загрузчик реестра МКД АИС ФРТ → обогащение houses ... Открытые данные АИС ППК «ФРТ» (бывш. Реформа ЖКХ), node 110 = реестр МКД региона 66: 41 790 строк, houseguid (ФИАС GUID) заполнен на 100% → join к houses.gar_house_guid без канонизации адреса. Анонимный GET, без ЕСИА. Заполняет ТОЛЬКО NULL-поля houses: year_built, material_walls, material_floors, total_floors, entrances, is_emergency, flat_count, heat_supply_type, gas_supply_type, hot_water + новые area_land, foundation_type, elevators_total. Замер по ЕКБ: wall_material 92.5% (было 75% от ДОМ.РФ), built_year 92.0% (было 86%), area_land 86.8% и is_emergency — признаков, которых не давал ни один из текущих источников. Осознанно НЕ мапится: - project_type → series_name: свободный текст и фактически дубль материала стен (пусто у 10 635 строк, «кирпичный» 1754, «нет данных» 1496); - energy_efficiency: решение миграции 284 + реальный класс лишь у ~10% домов (у 25 595 из 41 790 значение «Не присвоен»); - elevators_count → passenger_elevators: в источнике это ОБЩЕЕ число лифтов, в houses раздельно пассажирские и грузовые → отдельная колонка; - playground/sportsground: в источнике id справочника (498/499/500), не флаг. Дубликаты houseguid реальны и взаимодополняющи: 912 guid'ов, 968 лишних строк, у одной строки пары заполнен area_total, у парной нет. Строки СЛИВАЮТСЯ по полям (первое непустое побеждает), иначе бэкфилл терял бы данные ~2% домов. estimator.py не тронут: аналоги подбираются FROM listings без JOIN к houses, встраивание признаков в подбор когорты — отдельная задача. Миграции 290 (staging frt_mkd + колонки houses) и 291 (сид расписания, enabled=false, interval_days 30). robots.txt источника требует Crawl-delay 10.	2026-09-09 00:33:09 +03:00
lekss361	e2045582ab	Merge pull request 'feat(tradein/rosreestr): импорт ДКП по Москве (77) — canonical_city, raw_payload, wildcard-расписание rosreestr_dkp_import_*, per-source чекпоинт (#3051)' (#3422) from feat/3051-rosreestr-import-region-param into main	2026-09-08 20:28:20 +00: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	fbe85fcc75	feat(tradein/estimator): регион-скоуп ДКП-коридора — фильтр по d.region_code (#3051 PR-A) ... target_city резолвится ТОЛЬКО для городов Свердловской области (_resolve_target_city матчит SVERDLOVSK_OBLAST_CITIES) — для Москвы/любого нового региона city=None, и street ILIKE оставался единственным скоупом сделки: одноимённая улица чужого региона утекала в коридор. Добавлен d.region_code = CAST(:region_code AS int) в оба ДКП-запроса (_fetch_dkp_corridor) + region_code передаётся из обоих вызывающих (POST /estimate через geo.lat/lon, GET-rehydrate через row.lat/lon) с гарантией «не резолвится → DEFAULT_REGION_CODE (66)», не NULL (NULL в SQL-параметре обнулил бы фильтр целиком). Дефолт региона и джойн deal_city_price_bands не трогаются — следующие PR (B, F). Regression: 5622 passed, 37 skipped (полный прогон tests/).	2026-09-08 23:12:12 +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