673 commits

Author	SHA1	Message	Date
bot-backend	99f112db0b	Merge pull request 'fix(tradein/auth): единый источник ролей — БД first, YAML только legacy-fallback (закрывает эскалацию до admin и 403 своим)' (#3331) from fix/3316-role-single-source into main	2026-09-05 17:37:38 +00:00
bot-backend	f2f9ac941b	fix(tradein/pdf): клиентский PDF не называет площадки-источники — «Источник N», как в веб-отчёте (#3341) ... Веб-отчёт и лендинг с #3342 не показывают названия площадок (канон publicLabel в frontend/src/lib/source-registry.ts), а клиентский PDF по тому же /estimate/{id} печатал Avito / Циан / «Домклик · Сбер» / Я.Недвижимость / Этажи в пилюлях источников, «подтверждают Росреестр, ДомКлик…» в советах и «на Циан, Авито, Я.Недвижимости» в тарифах. Один клиент — два документа с разной нормой, и юр-риск, ради которого всё делалось, в PDF оставался открытым. - `_SOURCE_DISPLAY_NAMES` → публичные лейблы 1:1 с реестром фронта: avito → «Источник 1», cian → 2, yandex → 3, domklik → 4, etazhi → 5, rosreestr → «Росреестр»; fallback для незнакомого id — «Другой источник», а не `source.title()` (сырой id — та же утечка). - Алиасы (avito_imv, cian_valuation, yandex_valuation, domclick, etagi) канонизируются ДО выбора цвета и лейбла (`_canonical_source`), а списки источников на страницах объявлений и сделок дедуплицируются до среза [:5] (`_public_sources`): иначе `sources_used` = listing ∪ valuation давал «Источник 1, Источник 1, Источник 2, Источник 2, Источник 4» с серой точкой у алиасов и вытеснял yandex. - Цвета пилюль не тронуты: цвет — опознаватель источника, как на вебе. - Тексты: «Росреестр, сделки площадок и продажи агентств», «на основных площадках объявлений» (двойник offer-rates.ts). - Гейт `tests/test_pdf_public_source_labels.py`: видимый текст страниц (без тегов и атрибутов, href на домены площадок законны) не содержит названий площадок и сырых id, по одному кейсу на имя; дедуп алиасов; ветка совета с процентом. Не тронуто: ссылки на объявления (avito.ru/domclick.ru) — отдельное решение; `_QUALITY_SOURCE_SLOTS` — только счётчик, имена не рендерит.	2026-09-03 11:58:45 +03:00
bot-backend	5541aa9d37	fix(mera-public): публичная копия — сервис не называет себя оценщиком, площадки-источники не названы ... Три юр-правки по документу владельца продукта «Сайт_МЕРА_v2» (31.08.2026), сделаны локально 31.08, но не были закоммичены — на meraocenka.ru всё оставалось по-старому. 1. «Оценщик» про собственный алгоритм. Витрина сделок (`landing_showcase_deals.py`, REJECTION_RULE/NOTE) и сноска статьи «Как оценить квартиру» теперь говорят «расчёт МЕРЫ»: самоназвание обесценивало дисклеймер «не официальный отчёт оценщика». Комментарии и докстринги не тронуты — посетитель их не видит. 2. «Путь 2»: «стоимость услуг фиксированная и известна заранее» — читалось как фиксированная цена квартиры. 3. Названия площадок убраны из видимой копии лендинга и веб-отчёта. Канон — `publicLabel` + `sourcePublicLabel()` в `source-registry.ts`: одна площадка = один номер «Источник N» и один цвет точки (цвет остаётся опознавателем между блоками), Росреестр под своим именем, неизвестный id → «Другой источник» (раньше fallback отдавал сырой id). Три параллельные реализации `sourceLabel` сведены к одной; `sourceLabel()` с реальными именами живёт для админки. Backend: якорь confidence_explanation «по оценке Avito IMV» → «по оценочной модели площадки». Подсказки геокодера «Yandex / Nominatim» и «по Яндексу» сняты из клиентских форм. Гейт `public-copy-no-platform-names.test.ts` сканирует mera-public/** и components/trade-in/** без комментариев, по Unicode-границе слова; список запретов регистрозависимый намеренно (строчные id `"avito"` законны), поэтому капс-варианты и словоформы перечислены явно — «6202 ОБЪЯВЛЕНИЯ ДОМКЛИК» в статье именно так проходил первую версию гейта. Не закрыто здесь: клиентский PDF (#3341) и ссылки на объявления на доменах площадок. Текст витрины хранится в БД (`landing_showcase_runs.rejection_rule`, `landing_showcase_deals.note`), планировщика у пересчёта нет — после деплоя нужен ручной пересчёт или UPDATE трёх подстрок на проде.	2026-09-03 09:50:41 +03:00
bot-backend	4feb61c006	fix(tradein): резолвить роль из реестра, roles.yaml — только fallback (#3316) ... Роль жила в двух местах сразу: люди заводятся в БД (`tradein_users.role`), а `get_role` читал ТОЛЬКО `auth/roles.yaml` — и никто эти два источника не сверял. Дефект двусторонний: * вверх: менеджер заводил сотрудника с именем, которое уже числится в roles.yaml админом (проверялись лишь regex и уникальность в БД) — на входе тот получал admin из YAML, то есть чтение ЛЮБОЙ чужой оценки (admin проходит мимо ownership-check в trade_in.py) и безлимитную квоту; * вниз: сотрудник, которого в roles.yaml нет, ловил KeyError → 403 на СОБСТВЕННУЮ оценку. Источник теперь один и лечится один раз — в `app.core.auth.get_role`: реестр (`tradein_users.role` / `auth.users.role`) спрашивается первым, roles.yaml остаётся fallback для legacy-юзеров, у которых строки в реестре нет. Реестр недоступен → тоже fallback: падение БД не выключает legacy-вход. Вызывающие (rbac, trade_in, team, account_quota) не менялись. Сопутствующее, чтобы поведение существующих аккаунтов не поехало: * rbac_guard выбирает матчер путей по РОДУ роли (роль реестра → DB_ROLE_PATHS), иначе employee/manager на legacy-пути получил бы 403 на всё; * get_user_scope отдаёт scope роли реестра из того же DB_ROLE_PATHS; * право на персональный `unlimited` осталось за roles.yaml (account_quota + _batch_quota_status) — фикс убирает эскалацию, а не раздаёт новую; * `_batch_quota_status` берёт роли из уже прочитанных строк — иначе список «Команды» снова стал бы N+1. Defense-in-depth: create_employee отдаёт 409 на username, за которым в roles.yaml числится не-employee роль.	2026-09-02 14:49:27 +05:00
bot-backend	d708f15019	fix(tradein/support): один повтор терял каждое одиннадцатое сообщение в поддержку ... Замер прода 01.09.2026 из контейнера бота: канал до api.telegram.org рвётся всплесками, доля отказов на попытку 15-38% (пять проб: 3/8, 15/40, 5/20, 3/20, 1/25), в логе long-polling'а 353 ConnectTimeout за сутки. Транспорт ни при чём — httpx и сырой сокет отваливаются одинаково (25% против 35% в чередующемся замере), и прокси не помогает, а мешает: через SCRAPER_PROXY_URL 0 из 20. Ручка веб-поддержки ходила с max_retries=1, то есть двумя попытками. При 30% отказов на попытку до пользователя доходило ~9% отказов — каждое одиннадцатое сообщение возвращало 502 «сервис недоступен». Два других числа из того же замера задают конструкцию. Успешный запрос отвечает за 0.13с (максимум из 25 проб — 0.18с), а неудачный НИКОГДА не отваливается быстро: все отказы упираются в таймаут целиком (10.02с при timeout=10.0). Значит десятисекундный таймаут не покупал ничего, кроме цены за неудачу, — снижен до 5с, это ~28-кратный запас к измеренному максимуму. И экспоненциальная пауза 2→4→8с здесь бессмысленна: отказ — неустановленное соединение, а не троттлинг, пережидать нечего; она лишь добавляла 14с к ожиданию. Правка: бюджет ручки — 3 повтора, таймаут 5с, потолок паузы 1с. Худший случай 4 попытки × 5с + 3 паузы × 1с = 23с и требует четырёх отказов подряд; типичный случай не меняется (0.13с). Расчётная потеря падает с ~9% до ~0.8%. В TelegramClient добавлен необязательный max_backoff. Воркерная политика НЕ меняется: без явного потолка откат прежний экспоненциальный до 30с, а retry_after из 429 уважается целиком — эту границу держит отдельный тест, потому что первая версия правки её сломала (капала 60с до 30с и для воркера тоже). Потолок на retry_after применяется только когда его передали явно: интерактивному пути нельзя ждать Telegram-овские 30-60с, за ним стоит открытый запрос от браузера. Тесты: 8 новых (потолок на network/429/5xx, неизменность воркерного пути, арифметика «max_retries=N → N+1 попыток», границы бюджета ручки).	2026-09-01 09:53:21 +03:00
lekss361	4c29b59041	fix(tradein/proxy): успешный fetch затирал exit_ip и latency_ms в NULL (#3283) (#3305) ... Co-authored-by: lekss361 <lekss361@gendsgn.local> Co-committed-by: lekss361 <lekss361@gendsgn.local>	2026-08-31 14:53:33 +00:00
lekss361	b7c1c4d9d4	fix(tradein/proxy_pool): истёкший прокси больше не выдаётся в аренду (#3303)	2026-08-31 11:54:54 +00:00
lekss361	ea8943e00e	Merge pull request 'chore(tradein/scheduler): добор карточек Яндекса и Циана шёл раз в сутки и простаивал' (#3301) from chore/cadence-yandex-cian-detail into main	2026-08-31 11:36:24 +00:00
bot-backend	4ddb3c7196	chore(tradein/scheduler): добор карточек Яндекса и Циана шёл раз в сутки и простаивал ... compute_next_run_at держит суточную гранулярность (interval_days, минимум 1), подчасовой такт делается хуком reschedule_after_minutes как post_claim. У avito_detail_backfill он есть (180 мин), у yandex_detail_backfill и cian_detail_backfill не было — отсюда один прогон в сутки. Цена простоя по замеру прода 31.08: Яндекс: 375-450 карточек за прогон, блоков НОЛЬ за неделю, очередь 11110 → 25 суток при нынешнем такте Циан: блоков ноль, очередь 20501 Такты разные, и это не произвол: yandex — 180 мин (8 прогонов/сутки). Ходит через resolve_proxy_url: берёт URL узла, но НЕ лизует его, поэтому чужие прогоны не блокирует. cian — 360 мин (4 прогона/сутки). Ходит через BrowserFetcher и ДЕРЖИТ lease весь прогон, то есть отнимает узел у Авито и Домклика. Пул дефицитен (#2638), поэтому осторожнее. Асимметрия зафиксирована комментарием у обоих хендлеров и в докстринге миграции — иначе следующий читатель выровняет интервалы и сожжёт пул. Тест test_cian_default_interval_is_360_minutes_not_180 ассертит именно неравенство, чтобы выравнивание без замера покраснело. 283_scrape_schedules_cadence_yandex_cian_detail.sql — идемпотентный UPDATE ... SET default_params = default_params || jsonb, остальные ключи параметров не трогает. Значения 180/360 — консервативная отправная точка по аналогии с Авито, а не найденный оптимум: двигать вниз только по замеру нескольких суток, глядя и на свипы тоже (тот же довод, что в комментарии у avito_detail_backfill). Тесты (5): наличие post_claim у обоих, дефолтные интервалы, переопределение через params. Прогон: 397 passed, 1 skipped, ruff чист.	2026-08-31 14:17:12 +03:00
lekss361	a256077211	feat(tradein/proxy_rotation): ротация IP через mobileproxy.space (aproxy.site) (#3298)	2026-08-31 11:01:41 +00:00
bot-backend	5f9dc5d512	feat(tradein/cian): у Циана не было добора карточек — только побочный эффект задачи про историю (#3284) ... Карточки Циана доставались побочным эффектом cian_history_backfill, а её выборка ключуется по offer_price_history. Следствия на 30.08: карточка есть у 4494 из 25222 объявлений (17.8% — последнее место при втором месте по объёму), 19046 без истории при квоте 100/сутки (190 дней на остаток, тогда как очередь растёт вдвадцатеро быстрее), и 1697 объявлений с историей и без карточки, которые исторической выборке недостижимы в принципе. Фетчер при этом исправен: прогоны 5154/5240/5328 дали 100/100, 99/100, 100/100. Чинить нечего — не выдана мощность. Добавлен второй режим выборки (listings_pending="detail", по detail_enriched_at, свежие первыми) и второе расписание поверх ТОГО ЖЕ тела: машинерия работает, дублировать её новым модулем незачем. Историческая выборка оставлена побайтово — по ней живёт суточный прогон. batch_size=400 не на глаз: замеренный темп ~28с на объявление, порог reap_zombies 6ч по heartbeat, бюджетного сторожа у задачи нет — 400×28с≈3.1ч проходит, 800 как у Яндекса (≈6.2ч) убивало бы жнецом. Расписание засеяно enabled=false, как domclick_detail_backfill в миграции 175: это третий круглосуточный добор на общий пул из четырёх узлов, влияние на соседей надо посмотреть, а не предположить. Тесты: 13 проверок, ключ выборки / порядок / неизменность прежнего режима / проводка параметров через посредника / регистрация обоих source. Проверено мутациями: снятие ORDER BY, молчаливый дефолт вместо ValueError и потеря listings_pending в посреднике роняют по 2-3 теста каждая. Набор целиком — 5196 passed, 37 skipped.	2026-08-30 15:34:36 +03:00
bot-backend	663d63aea4	fix(tradein): подсказки адреса — пустые части адреса выпадают, а не печатаются ... Прод отдавал «г Екатеринбург, ул Фролова , д. 29, корп.»: реестровый readable_address (ЕГРН) приходит УЖЕ склеенным вместе с пустыми частями — маркер без значения печатается, лишний пробел перед запятой остаётся, и все тиры /suggest (cadastral / geoportal / houses / DaData / Nominatim) пропускали строку насквозь. Чиним склейку, а не конкретный случай: `tidy_address()` — один проход по частям (схлопнуть пробелы, выбросить пустые и маркер-без-номера: корп./стр./лит./кв./оф./пом. и пр.), склейка обратно. Применяется в `GeocodeSuggestion.__post_init__` — единственной точке, через которую проходят все тиры, включая локальные, которые питают и `geocode()`. Тест на функцию склейки, фальсифицирован снятием фильтра пустых: краснеет по значению строки (10 из 14), а не исключением. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 14:58:03 +05:00
bot-backend	44633b0df4	fix(tradein/domclick): свип ходил на QRATOR без кук и вис на PoW каждым запросом (#3264) ... serp.py не передавал куки сессии вообще — слова cookie в файле не было. Свип приходил к QRATOR с чистым браузером и был обязан решать proof-of-work с нуля на каждый запрос. Прод, прогон 5330 (30.08 03:49-03:55): 9 запросов к bff-search-web.domclick.ru, все 9 зависли на челлендже (перезагрузка 1/2, 2/2, отказ), status=failed, 0 лотов. Прокси при этом ротировался (узел 9 → 10) — узел тут ни при чём. Добор с тем же сайдкаром и тем же пулом в ту же ночь взял 37 карточек из 37 без единого блока. Разница ровно в куках. Чинить это стало возможно только сейчас: свип ходит не на ekaterinburg.domclick.ru, а на отдельный хост bff-search-web.domclick.ru, и до правки _cookie_domain (PR #3262) куки легли бы на .bff-search-web.domclick.ru, не совпав с сессией площадки. Теперь оба хоста схлопываются в общий .domclick.ru. Снимок приходит параметром снаружи, а не читается внутри kit: kit не импортирует app.* (strangler-инвариант #2133). Поэтому джоба domclick_city_sweep переопределена продуктовым Handler'ом — build_registry это прямо допускает («последнее слово за продуктом»), а БД читает только app-сторона. Отсутствие сессии не авария: load_session вернул None → свип идёт как раньше, без инъекции, факт логируется один раз. Цена решения — override повторяет вызов kit-джобы целиком и может тихо с ней разойтись. Добавлен тест, который зовёт оба джоба одинаково и сравнивает наборы kwargs, допуская расхождение ровно в cookies. Проверен мутацией: с искусственно добавленным в kit-версию аргументом краснеет, без него зелёный. Тесты: 245 passed, 1 skipped (domclick + parity).	2026-08-30 09:40:21 +03:00
bot-backend	ca3f073b0e	feat(mera/b2c): улица сделки доезжает до витрины готовой схемой, а не геометрией ... Карта в карточке игры показывала полигон района — единственную геометрию, до которой у tradein был доступ. Улицы живут в базе gendesign, foreign table и гранта на них не было. Мост по образцу соседей (v_tradein_cad_buildings / v_tradein_osm_poi_ekb): gendesign 195 — вьюха v_tradein_osm_roads_ekb (highway + water) с GRANT В ТОМ ЖЕ ФАЙЛЕ (после #3227 грант отдельной миграцией теряется при пересоздании); tradein 281 — foreign table gendesign_osm_roads_ekb плюс колонки street_name / street_scheme в landing_showcase_deals. Пересчёт витрины кладёт в строку УЖЕ СПРОЕЦИРОВАННЫЕ SVG-пути окна 840x840 м вокруг центра улицы. Проекция — та же равнопромежуточная с cos(широты), что в export_ekb_districts_svg.py; второй в проекте нет. Замер 2026-08-29: GeoJSON того же окна 7-8 КБ на строку, схема — 2.8-2.9 КБ. ЧТО ДАННЫЕ ВЫДЕРЖИВАЮТ, И НИ СЛОВОМ БОЛЬШЕ · Это УЛИЦА, а не дом: deals.address уровня улицы, номер дома у 2.7% сделок. В схеме намеренно НЕТ координат окна и констант проекции — точку дома по ней нельзя поставить даже случайно. Это замок, а не забывчивость. · Зданий нет: cad_buildings — 18 307 контуров на город, в плотном центре 51 здание на радиус 450 м, где их в разы больше. Нарисованная застройка заявляла бы полноту, которой в данных нет. · Улицы — фильтрованная выгрузка «источников шума»: именованные покрыты хорошо, дворовые и служебные проезды отсутствуют. · Улица сматчилась у 550 названий из 654 — 31 410 сделок из 34 021 (92.3%). Остальным street_scheme = NULL, и это штатно: фронт показывает район, который для этого и оставлен. · Перекрёсток («Челюскинцев/Шейнкмана») берём первой улицей: таких адресов три на 34 021 сделку, и обе улицы одинаково верны на уровне улицы. · Наличие схемы НА ОТБОР СТРОК НЕ ВЛИЯЕТ — то же правило, что запрещает отбор по величине ошибки: иначе витрина показывала бы не работу оценщика, а те 92% адресов, что удобно легли на OSM. Тесты (каждый сломан вручную и покраснел): нормализация на реальных адресах включая ё/е и «8 Марта»; недоступная вьюха и упавший запрос дают None, а не исключение; схема не раздувается — потолок в байтах на реальной плотности плюс прямая проверка округления до 0.1.	2026-08-29 23:25:44 +05:00
lekss361	6dd8d131ae	feat(mera/estimate): характеристики дома из справочника, а не только из формы (#3242)	2026-08-29 18:06:17 +00:00
lekss361	195f9f3697	Merge pull request 'chore(tradein): две ручки ротации без читателей и врущий комментарий над ними' (#3232) from chore/3212-dead-rotation-knobs into main	2026-08-29 14:57:40 +00:00
lekss361	7563f849db	Merge pull request 'chore(tradein): четыре символа, на которые нет ни одной ссылки' (#3224) from chore/3212-dead-code-tradein into main	2026-08-29 14:57:28 +00:00
bot-backend	1141035899	chore(tradein): две ручки ротации, которых не осталось читателей, и врущий комментарий над ними ... proxy_rotate_attempts / proxy_rotate_attempt_timeout_s тюнили ретраи changeip-GET. Сам changeip снят в #2616 шаг 2 (аккаунт mobileproxy закрыт, ссылки нет), и с тех пор ручки живут пламбингом: Settings -> property адаптера -> поле протокола ScraperConfig -> и всё. Ни одного потребителя, только четыре теста, которые заполняют их при сборке конфига. Комментарий над ними в contracts.py оправдывал их сохранение так: «оставлены как budget-верхняя-граница для app.tasks.avito_detail_backfill wait_for» — но wait_for там берёт СОСЕДНЕЕ поле, avito_proxy_rotate_settle_s (avito_detail_backfill.py:249). То есть комментарий приписывал этим двум полям работу третьего и тем самым прикрывал их мёртвость. Соседние ручки проверены и ОСТАВЛЕНЫ, они действительно читаются: * avito/cian/yandex_proxy_max_rotations — pipeline._max_rotations; * avito_proxy_rotate_settle_s — asyncio.wait_for в avito_detail_backfill. Заодно сжат комментарий в config.py: перечисление истории changeip заменено на то, что нужно знать сейчас — кто читает оставшиеся две ручки и где живая ротация (ASOCKS_API_TOKEN / proxy_rotation, #2611). ruff clean, 4974 passed / 37 skipped.	2026-08-29 17:07:04 +03:00
bot-backend	b5645ec1bc	feat(mera/b2c): витринные метрики лэндинга считаются по проду ... Числа на публичном лэндинге лежали литералами во фронте (mera-public/marketing-v3.ts) — то есть были выдуманы и не имели срока годности. Теперь их считает ночная задача и отдаёт публичная ручка, вместе с размером выборки и описанием того, что именно измерено. Что считается: число расчётов и период работы, медиана аналогов на расчёт, медианная ЭКСПОЗИЦИЯ активного объявления по ЕКБ (не срок продажи — так и написано в note), доля снижавших цену и медианное снижение за 30 дней, сделки Росреестра по ЕКБ за 12 месяцев. Ценовые метрики берут ТОЛЬКО domklik: у avito/yandex триггер не пишет стартовую цену, а yandex вдобавок сеет синтетическую пару со сдвигом в сутки — на такой смеси «снизил» и «не снижал» неразличимы. Знаменатель доли — все объявления, наблюдавшиеся от 14 дней, включая не менявшие цену; считая только по менявшим, получили бы 85% вместо честных 48%. Метрика без входных данных строку НЕ пишет: подставленный ноль читался бы как измеренный ноль. Пустая таблица — валидные {} и 200, а не 500. «Точность прогноза» и «срок продажи» здесь не считаются намеренно — таких величин в данных нет.	2026-08-29 18:45:26 +05:00
bot-backend	4902d1e29e	chore(tradein): четыре символа, на которые нет ни одной ссылки ... Найдено сверкой двух независимых источников: подсчёт упоминаний по всем python-файлам (включая тесты) дал имена, встречающиеся ровно один раз — в собственном объявлении; каждое затем подтверждено serena find_referencing_symbols (LSP, видит и косвенные ссылки) и проверено grep'ом по yml/sql/ts/md на случай ссылки строкой. Удалено: * _qr_code_data_url (trade_in_pdf) — QR как SVG data URL, не вызывался ниоткуда; вместе с ним ушёл осиротевший import segno. `io` ОСТАВЛЕН — io.BytesIO используется дальше по файлу (строка 774); * _local_name (gar_flats_loader) — снятие namespace с имени тега; * AvitoParseError — класс никто не поднимает и не ловит; * IMVCityMismatchError — то же. Что НЕ тронуто, хотя фильтр их показал: * ~200 обработчиков FastAPI и celery-задач — их поднимает декоратор, по имени их действительно никто не зовёт; * refresh_ddu_price_indicator — точка ручного обслуживания, задокументирована в комментарии к матвью (data/sql/152_mv_ddu_price_indicator.sql: «Refresh: ... (не в beat)»); * schemas/parcel.py::MarketPrice — половина контракта, фронт использует (frontend/src/types/site-finder.ts: market_price?: MarketPrice); * JobSetting — SQLAlchemy-модель, живёт через metadata Base. segno остался в backend/pyproject.toml и больше нигде не используется — снятие зависимости требует пересборки лока, поэтому отдельным PR. ruff clean, 4974 passed / 37 skipped.	2026-08-29 15:59:54 +03:00
lekss361	cdcb152d76	Merge pull request 'fix(tradein/scrapers): ABORT-лог называл серию блоков, хотя рвал прогон по доле' (#3201) from fix/3184-abort-log-names-wrong-criterion into main ... Reviewed-on: #3201	2026-08-28 20:27:36 +00:00
lekss361	79e469de1c	Merge pull request 'fix(tradein/scrapers): диагноз блока из HTTP-статуса, а не из маркеров чужой площадки (#3196)' (#3202) from fix/3196-ban-kind-http-status into main ... Reviewed-on: #3202	2026-08-28 20:25:40 +00:00
bot-backend	bf3214b9e4	fix(tradein/scrapers): диагноз блока брался из текстовых маркеров чужой площадки, а не из HTTP-статуса (#3196) ... Сайдкар вообще не читал код ответа page.goto: страница классифицировалась только по маркерам, снятым с Авито. Домклик отдаёт статическую `403 | Домклик` на 26 624 байта, где нет ни одного такого маркера (замер прода 28.08.2026) — она уезжала наверх как валидный HTML, парсер не находил состояние, и прогон получал блок неизвестной природы. За 14 дней все 14 прогонов домклика легли с ban_kind='unknown'; у Яндекса счётчика blocked не было вовсе, поэтому ветка перевода прогона в 'banned' была недостижима по построению — ноль банов. - browser/server.py: статус целевой навигации сохраняется per-provider и доезжает в тело /fetch аддитивным ключом "status" (ключ "html" не тронут); 403/429 с маркерами челленджа больше не ждут PoW — ждать нечего, статическая страница сама себя не перезагрузит. Наверх идёт BanPageDetectedError, а не заглушка: вернув её контентом, воскресили бы #3045. - scraper_kit/browser_fetcher.py: BrowserFetcher.last_response_status + ban_kind_from_status (403/429 → platform, 5xx → infra, прочее → None). Поток управления не менялся: fetch() по-прежнему отдаёт str. - domclick: DomClickBlockedError несёт .status — один тип исключения на маркер-детект и на сбой фетча разводится без размножения типов; прогон передаёт перепись диагнозов в mark_backfill_finished. - yandex: появился счётчик blocked, оживляющий ветку бана. Серии блоков и промахов парсера считаются РАЗДЕЛЬНО: иначе четыре промаха плюс один 403 пятым давали 'banned' с переписью {platform: 1}. - cian: ban_kinds наполняется только диагностируемым статусом. HTTP 200 с пустым разбором — дрейф разметки на нашей стороне, а не отказ площадки; записав его блоком, мы бы штамповали фиктивные баны у здорового источника (13 done против 1 banned за 14 дней). Инвариант: непустой ban_kinds ⟺ виден ответ 403/429/5xx. Значения остаются в пределах CHECK scrape_runs.ban_kind. Известный пробел: шов providers/domclick/detail.py `blocked.status = status` тестами не покрыт — существующие домкликовые тесты подают исключение готовым моком и боевой fetch_detail не исполняют.	2026-08-28 23:21:54 +03:00
bot-backend	8176e8d167	fix(tradein/scrapers): ABORT-лог называл серию блоков, хотя рвал прогон по доле ... Прод-прогон 5210 оборвался по ratio-критерию — 14 блоков из 20, ровно порог 0.7 — и отчитался строкой «ABORT -- 1 consecutive blocks». Число верное: последняя серия в тот момент действительно равнялась единице (19-я попытка успех, 20-я блок). Величина не та. Читатель лога видит цифру, по которой обрыва быть не могло, и идёт искать несуществующий баг в брейкере. Причина: #3184 заменил критерий обрыва на долю в скользящем окне, а текст лога остался от прежнего критерия «N подряд» — то есть ровно та же болезнь, которую #3178 лечил у соседней строки (литерал «IP rate-limited» вместо измеренной причины). - BlockRatioBreaker.abort_reason() возвращает "ratio" / "safety_net" / None; should_abort() выражен через него, поведение не меняется. - abort_explanation() даёт текст с той величиной, по которой обрыв и произошёл: доля печатает «доля блоков 14/20 в окне (порог 70%)», safety-net — «5 блоков подряд без единого успеха (снапшот 5 короче окна 20)». - counters["abort_reason"] — чтобы причина обрыва читалась SQL-запросом по scrape_runs, а не грепом контейнера. Ключа нет, если прогон не обрывался. Тесты (проверено мутацией источника — на прежнем сообщении оба падают): - ratio-обрыв на раскладке прогона 5210 (серия на обрыве = 1) требует «14/20» в логе и отсутствия слова consecutive; - safety-net требует «5 блоков подряд» и отсутствия «доля блоков» — без этого зеркала первый тест проходил бы и у сообщения, всегда печатающего долю; - прогон без обрыва (13/20) не пишет abort_reason в counters. Refs #3184, #3178	2026-08-28 23:04:07 +03:00
bot-backend	c995af73c2	docs(tradein/scrapers): в репозитории лежало опровергнутое обоснование хранилища сессий Яндекса ... #3195 замержен с утверждением, что авторизованная сессия раскрывает контакты продавца. Утверждение неверно, а лежит оно в двух местах, которые читают в первую очередь: докстринг app/services/yandex_session.py и шапка миграции 274. Повторный замер (#3192, 2026-08-28) сделан на ПРОД-транспорте — curl_cffi + прокси из пула, тот же путь, что у yandex_detail_backfill, — а не на сайдкаре, как первый: - offerCard.card.author у целевой карточки не несёт phones/phoneNumbers ни в одном из 12 случайных объявлений (6 AGENCY, 6 DEVELOPER), одинаково с куками и без; только encryptedPhones (1 токен) и redirectPhones; - phoneNumbers во всём INITIAL_STATE встречается только под offerCard.visitedOffers[*].author — истории просмотров НАШЕЙ учётки; анонимно список пуст, с куками в нём 9-10 записей; - первый замер («0 → 3,4,5,6») считал рост именно этой истории: +1 на каждый фетч; - authorStats.phones (коммутатор застройщика) отдаётся анонимно — тот же номер в обеих ветках. Правка только текстовая: ни схема, ни поведение не меняются. Шапку применённой миграции правлю сознательно — файл повторно не выполняется (учёт по имени в _schema_migrations), а неверное описание пережило бы любой следующий разбор. Таблицу не трогаю: она пуста, но DROP без явного решения владельца делать нельзя. Судьба #3195 — на владельце, #3192 помечен needs-human. Refs #3192, #3195	2026-08-28 22:52:47 +03:00
bot-backend	5be64c6688	fix(tradein/scrapers): хранилище авторизованной сессии Яндекс.Недвижимости (#3195)	2026-08-28 19:02:05 +00:00
bot-backend	49b70a67f3	fix(tradein/scrapers): обрыв по серии блоков рвал каждый прогон, включая здоровые (#3188)	2026-08-28 18:22:25 +00:00
bot-backend	e685f96107	fix(tradein/scrapers): диагноз блока терялся при схлопывании, а в алерт шла непроверенная причина (#3183)	2026-08-28 17:15:02 +00:00
bot-backend	51027d8b02	fix(tradein/ingest): rosreestr_dkp_import курсор переживает рестарт (#3168) ... last_id жил только в памяти процесса (import_rosreestr_dkp, scheduler.py): heartbeat писал его в scrape_runs.counters каждый батч (комментарий рядом прямо называл это чекпоинтом), но при старте last_id всегда инициализировался литералом 0 — обрыв (деплой/OOM/рестарт хоста) откатывал прогресс и заставлял пере-сканировать источник с начала. Разведка: из пяти backfill-циклов issue (avito_detail_backfill, house_imv_backfill, cian_history_backfill, yandex_detail_backfill, geocode_missing_listings) ни один не имеет этого дефекта — все устроены как WHERE ... IS NULL/NOT EXISTS ... LIMIT, естественно резюмируемы без курсора. Единственный код, буквально описанный в issue (строки/SQL/комментарий), это шестой, не входящий в таблицу backfill — rosreestr_dkp_import. Фикс — _resume_dkp_cursor(db, run_id): - кандидат — последний прогон source='rosreestr_dkp_import'; - резюмится только незавершённый штатно прогон: status running/zombie, либо done с counters.interrupted=1 (SIGTERM-drain — эта ветка раньше считала последующий full rescan штатным поведением, теперь помечает себя как прерванную и резюмится наравне с zombie); - потолок возраста чекпоинта — 24ч, старше — 'checkpoint_stale', старт с 0; - чистый 'done' (полный проход) не резюмится — иначе ON CONFLICT DO UPDATE перестанет ловить правки уже импортированных сделок при следующем проходе. Вердикт и per-batch чекпоинт пишутся через kit_runs.update_heartbeat (merge `counters || :counters`) вместо локального runs_mod.update_heartbeat (полная замена) — иначе resume-вердикт стирался первым же heartbeat'ом батча. Тесты: tests/test_3168_backfill_cursor_resume.py — резюм с сохранённого last_id, резюм после SIGTERM-drain, отказ резюмить чистый done, отказ резюмить протухший (>24ч) чекпоинт, merge не стирает посторонние ключи. Обратимость проверена вручную (временный откат _resume_dkp_cursor красил 6 из 8 тестов).	2026-08-28 01:08:21 +03:00
bot-backend	c01ec805df	fix(tradein/tgbot): в логе сетевого сбоя не было причины — только пустота после двоеточия ... Замер на проде 27.08: `getUpdates` падает 23 раза в сутки, 14 из них за один час. Ретрай почти всегда чинит с первой попытки, поэтому сообщений не теряется — теряется возможность понять, что происходит: network error (попытка 1/3): — retry через 2s После двоеточия пусто. У httpx.ReadError и httpx.ConnectError `str(exc)` пуст, а тип исключения в строку не попадал. По такому логу не отличить таймаут от обрыва соединения от сброса TLS, то есть 23 события в сутки не дают ни одной зацепки. Сеть при этом цела: сырой TLS до Telegram проходит 6 из 6 попыток за ~0.16s. Тип добавляется к тексту, а не вместо него: на исключениях с внятным сообщением диагностика не должна стать беднее прежней. Оба конца закреплены тестами — с пустым текстом и с непустым. Closes #3156	2026-08-27 21:58:51 +03:00
bot-backend	dd3a79b475	style(tradein): уложить перенесённые строки в лимит 100 символов ... Ruff E501 на трёх строках, которые удлинились от замены литерала на `DEFAULT_IMPERSONATE` в докстроках. Абзацы перевёрстаны целиком, а не разорваны по месту переполнения — рваный перенос читался бы как опечатка. Прогон: `ruff check app tests` — All checks passed. Refs #3148	2026-08-27 18:24:09 +03:00
bot-backend	cf3d4850e2	fix(tradein/scrapers): три прод-пути остались на chrome120, пока kit ушёл на chrome146 ... #3034 свёл impersonate к единственной константе внутри scraper_kit и поднял профиль до chrome146. Сторож литерала сканирует только пакет, а его докстрока объявила остальное «отдельным периметром вне scope», сославшись на #2361 F4a. Периметр не спящий — он ходит в сеть каждый день, а #2361 к тому моменту был закрыт, то есть отсылка вела в никуда. На chrome120 оставались: app/services/cian_session.py:164 верификация куки Циана app/services/yandex_address_backfill.py:153 бэкфилл адресов app/tasks/yandex_detail_backfill.py:303 detail-бэкфилл Разрыв в 31 мажорную версию живёт в TLS-отпечатке (JA3/JA4), а не в строке User-Agent, поэтому сменой прокси он не лечится. ПРО ЦИАН ОТДЕЛЬНО. По #2673 оценка Циана мертва с 29 июня — «куки протухли, ни одной новой строки 37 дней». Путь, которым проверяется живость этих куки, всё это время представлялся площадке браузером двухлетней давности. Причину этим не объявляю: утверждаю, что при таком отпечатке отличить «куки протухли» от «нас узнали по рукопожатию» нечем. ТЕСТ ЗАКРЕПЛЯЛ ДЕФЕКТ. test_cian_session прибивал chrome120 гвоздём: подъём профиля в kit ронял бы этот тест, а «починкой» выглядел бы возврат к устаревшему профилю. Теперь тест сверяется с DEFAULT_IMPERSONATE. Сторож литерала расширен на backend/app — без этого периметр возвращается молча, что уже один раз и произошло. Намеренно НЕ входят tests/fixtures/** (номер профиля там — часть записи о том, чем снят фикстур-HTML) и scripts/** (разовые инструменты, в прод-путях не участвуют). Исторические замеры в комментариях сохранены как замеры: «curl_cffi с kit-профилем (на момент замера — Chrome 120)» вместо переписывания истории. Проверено: сканер сторожа на дереве даёт ноль нарушителей, на подсаженном литерале краснеет; все изменённые модули компилируются. Refs #3148	2026-08-27 18:18:05 +03:00
bot-backend	27fdd55aae	feat(tradein/matching): region_code у houses — вывод, а не выдумка (#3051 п.4) ... Миграция 272: колонка + бэкфилл ТОЛЬКО по bbox региона 66 (значения байт-в-байт из реестра, синхронизацию держит тест). Карантин NULL: 620 домов без geom, 23 порченых (ЕКБ-адреса с чужими координатами — «Вильгельма де Геннина» на Байкале, «Крауля» под Москвой, «Учителей» в Таллине, с живыми ссылками листингов) — им регион не присваивается, включая 3 дома с координатами в bbox Москвы (порча, не переезд). NOT NULL из постановки — отдельной миграцией, когда карантин опустеет. Запись: новый дом наследует регион РАЗВЁРТКИ (base.py → контракт → адаптер → matching), только если координаты не противоречат; координаты другого региона → NULL-карантин + warning. Вне-bbox координаты при живой развёртке наследуют её регион (адрес и развёртка согласны, координатам веры нет) — семантика закреплена тестом, чтобы смена была осознанной. Матчинг-запросы НЕ тронуты — гард по региону это #3052. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 13:51:48 +05:00
bot-backend	0529bb249c	feat(tradein/geo): реестр регионов — единственный источник гео-границ (#3051, шард 1a) ... Границы покрытия лежали литералами в трёх файлах (location_index / geocoder / matching.normalize), и каждая молча отвергла бы Москву. Новый модуль app.services.regions — лист дерева импортов — держит per-регион bbox'ы (tight/wide/region/product_core), города, city_token и набор доступных тиров обогащения; потребители держат прежние имена как алиасы на объекты реестра (identity закреплена тестом — копии, разъезжающиеся при правке, невозможны). Регион 66 — байт-в-байт прежние литералы (закреплено тестом: этот PR только переносит границы, менять их = отдельное решение). Регион 77 (Москва): МКАД- ядро + генеральный bbox с Новой Москвой и Зеленоградом; тиров обогащения НЕТ ни одного — и это явный факт реестра с готовой формулировкой (unsupported_tier_reason), а не молчаливое «посчитаем без источника». Приёмка #3051: точка 55.75/37.62 больше не out_of_coverage — location_index узнаёт регион 77 и считает в его ядре (сегодня листингов Москвы нет → честный insufficient_data). Область 50 отложена по решению в #2996. Не здесь (следующие шарды): city_fias_id сквозняком (п.2), doc_type в deals (п.3), region_code у houses (п.4), депромоут описаний (п.5), параметры загрузчиков (п.6). Гейт ЕКБ-тиров геокодера (#2582) уже деградирует правильно для Москвы — fail-closed открывает их только при подтверждённом ЕКБ. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 18:39:28 +05:00
bot-backend	3d0541b2e2	Merge origin/main into fix/2656-anchor-ratio-freshness — конфликты: метки #2656→#2661 (main), импорт-union, baseline unrecorded=0 (перезахваченная фикстура)	2026-08-26 18:22:54 +05:00
bot-backend	0a85fa7202	fix(tradein/observability): результат detail-бэкфиллов доезжает до колонки total_seen (#3044) ... Прод-факт: замер по avito_detail_backfill прочитал «обогащено 0 за 7 дней» при реальных 801 — джобы пишут результат только ключом 'enriched', которого _column_counts не знал, и колонка total_seen оставалась 0 у всех прогонов. 'enriched'-фолбэк добавлен именно в _column_counts (витринная колонка), а НЕ в _RESULT_COUNTER_KEYS: тот список кормит zero-result-стрик, где догнавший очередь бэкфилл стал бы непрерываемым измеренным нулём — ловушка, за которую ревью уже выкинуло из списка 'rows_inserted' (#2703). Контракт стрик-сторожа закреплён инвариант-тестом. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 12:23:19 +05:00
lekss361	d409e31f00	feat(mera/b2c): анти-абуз для анонимного трафика — этап 2 из 8 (#2546)	2026-08-25 16:27:02 +00:00
lekss361	9810ae350f	feat(tradein/deactivate-stale): страховочные рельсы объёма снятия (#3066)	2026-08-24 08:44:32 +00:00
bot-backend	5b447ec33d	feat(tradein/estimate): внешние оценки не ждутся в запросе — 9 секунд превращаются в 1 ... Замер на проде 2026-08-22, разбивка одного расчёта по логам: 10.659 старт 10.827 дом найден 0.17 с 11.565 аналоги, 49 кандидатов 0.74 с 11.579 ДКП-коридор 0.01 с 17.576 yandex_valuation ← 6.0 с 19.159 cian_valuation ← 1.5 с 19.252 готово итого 8.6 с Семь с половиной секунд из восьми с половиной — ожидание чужих HTTP. Наша база и сам расчёт укладываются в секунду. По уже виденному адресу (кэш 24 ч) — 0.4-0.8 с, по новому — 8-12.4 с. Геокодинг ни при чём: с готовыми координатами те же 7.5-10.8. Публикация в РБК 30.08 приведёт аудиторию на НОВЫЕ адреса, то есть мимо кэша. Масштабирование контейнеров тут не помогает: время уходит на ожидание чужого ответа, а не на наши вычисления. Что сделано: у обоих источников появился режим «только кэш» (fetch_on_miss). При включённом ESTIMATE_EXTERNAL_SOURCES_BACKGROUND запрос делает лишь чтение кэша (локальный запрос на миллисекунды), а свежая загрузка уходит в фон и наполняет кэш к следующему обращению по тому же адресу. Почему это безопасно: деградация источника в None — НЕ новое состояние ответа. Ровно так же ведёт себя таймаут estimate_*_valuation_timeout_s, и этот путь работает в проде сегодня. Контракт API не меняется. Фоновая задача берёт СВОЮ сессию: сессия запроса закрывается вместе с ответом, а обе функции источников делают внутри себя db.commit() — переиспользование чужой сессии зафиксировало бы её незавершённую работу. По той же причине отвергнут наивный asyncio.gather двух источников на одной сессии. Очередь догрузки ограничена восемью задачами. Без потолка всплеск по новым адресам — ровно тот случай, ради которого режим и сделан — породил бы сотни параллельных задач с сессиями и HTTP-клиентами при max_connections 100 и mem_limit 768m у backend, то есть отказ вместо ускорения. Дефолт в коде False: поведение других окружений не меняется. На проде режим включён через docker-compose.prod.yml у сервиса backend. Отдельно НЕ сделано, хотя предлагалось: снижение таймаутов до 4 с. Замер показал, что свежий запрос к Яндексу занимает 6 с — таймаут 4 обрывал бы его почти всегда, кэш бы не наполнялся, и источник оказался бы тихо отключён. Таймаут здесь страховка от патологии, а не регулятор задержки. Тесты: 7 штук на режим «только кэш», собственную сессию, гашение ошибок, удержание ссылки на задачу и потолок очереди. Фальсифицированы — на неизменённом коде падают 5 из 7 (проходит только сторож неизменности дефолта). Смежные тесты оценщика (29 штук: бюджет ЦИАН, клиентские координаты, аудит) зелёные.	2026-08-22 15:51:31 +03:00
bot-backend	fa1399d59e	fix(tradein/avito): бэкфилл простаивал 23 часа из 24 — каденс был суточным ... Замер 2026-08-22, уже после починки транспорта (#3049): обогащение работает, но очередь не разбирается. За сутки 238 карточек при 9 951 активном объявлении. Причина в планировщике, а не в скрапинге. `compute_next_run_at` имеет суточную гранулярность по построению — `interval_days = max(1, int(...))`, целевая дата `now + interval_days`. Меньше суток не выражается. Бэкфилл при этом умирает по бану через 17-83 минуты, то есть работал около часа в сутки, а остальное время расписание ждало следующего дня. Механизм sub-hourly каденса уже был написан — `reschedule_after_minutes` (#2162, сделан для proxy_healthcheck). Его просто не подключили к бэкфиллу. Хук ставит next_run_at = now() + interval_minutes сразу после claim и сам себя тормозит: пока прогон идёт, has_running_run в _claim_run возвращает None. 180 минут — осознанно консервативная отправная точка, НЕ найденный оптимум. Данных для подбора нет, и имеющиеся два прогона противоречат наивному ожиданию: 4562 дал 175 карточек за 83 минуты, а 4586 через 4.3 часа — когда пул прокси был давно чист — умер за 17 минут с 42 карточками. Значит память Авито длиннее часов, и учащение может ухудшить выход. Отдельно держать в голове при подборе: те же 4 прокси обслуживают SERP-свипы, то есть первичный сбор. Сжечь их на обогащении хуже, чем медленно обогащать. Двигать интервал вниз только по замеру нескольких суток, глядя и на свипы. Подбор — через default_params расписания, правка кода для этого не нужна. Тесты закрепляют подключённость хука и коридор дефолта, а не конкретное значение: 180 будет двигаться, а вот утрата хука вернёт суточный простой молча. Проверено фальсификацией — на неизменённом коде все три падают.	2026-08-22 14:57:20 +03:00
bot-backend	cdf493f345	chore(format): нормализация под ruff 0.15.20 — 161 файл, только формат (#2864) (#3022)	2026-08-21 12:01:52 +00:00
bot-backend	6cdf56820d	fix(tradein): апсерт не переписывает неизменившуюся строку — гейт IS DISTINCT FROM + МСК-день (#2992) ... (полное описание — в PR) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 13:57:09 +05:00
bot-backend	865e64b783	feat(tradein/estimator): штраф за неизвестный год/тип дома — флагом, default OFF (#2936) ... В SQL-формуле relevance_score кандидат без year_built получает штраф 0 — столько же, сколько точное попадание в год, и лучше, чем кандидат с известным годом, отличающимся на 24 (2.0). То же с house_type. Отсутствие данных выигрывает у знания и возвышает источник с худшей полнотой. Флаг estimate_unknown_attr_penalty_enabled (default OFF): кандидат с NULL получает МЕДИАННЫЙ по пулу штраф того же признака среди тех, у кого он известен — не наказание и не награда; считается по тем же термам, что SQL (abs(Δyear)/12.0, 1.5 за несовпадение типа). Лежит в Python-слое после SQL, рядом с kitchen/ceiling (#2012), по тому же контракту: включать — только по бэктесту. Без чего флаг был бы мёртв (и был в первой редакции): _ANALOG_SELECT_COLS не выбирал year_built/house_type — SQL считал по ним CASE, но в словарь кандидата колонки не попадали, Python-слой видел None у ВСЕХ и не штрафовал никого по построению. Probe-лог в прод-оверлее: pool=30 null_year=30. Добавлены в _ANALOG_SELECT_COLS, во внешние SELECT тиров H/W и во внутренний base Tier W (он строится явным списком). Контроль: флаг OFF с колонками и без — метрики бэктеста идентичны до сотых. На этот инвариант стоит тест по исходнику запросов. Живой A/B (бэктест в прод-контейнере, оверлей /tmp/ab, 300 сделок ЕКБ Q2 2026, одна и та же выборка в обоих прогонах — проверено по deal_id): состав топ-50: сменилось 96 слотов из 5 915 (1.6 %), 27 сделок из 300 источники: avito 55.7→55.3 %, cian 24.5→24.8 %, yandex 12.7→12.6 % цена: MAPE 16.70→16.70, bias −4.52→−4.52, coverage 84.46→84.46 — идентично до сотых по всем срезам (сегменты, комнатность). Нижний Тагил (300 сделок, пулы 21/p90 40): 0 из 5 666 слотов сменилось. Почему эффект в разы меньше замера задачи (×0.20 avito): тот замер шёл по SQL тира H без стратификации. В боевом пути 54.9 % слотов топ-50 — гарантированная квота MIN_ANALOGS_PER_SOURCE=5, раздаётся ДО сортировки остатка; и у avito в топ-50 NULL-год лишь у 25.7 % (задача мерила 56 % по всем активным объявлениям). Обе величины измерены по фикстурам A/B. Что это значит: артефакт в формуле есть, флаг его корректно лечит, но на итоговую цену он не влияет измеримо. Включать по умолчанию оснований нет — и это и есть ответ, ради которого флаг заводился вместо правки. pytest tradein-mvp/backend: test_2936 7 passed; гейт фикстуры и roundtrip 8 passed; -k "estimat or analog" 735 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 13:27:18 +05:00
bot-backend	3b40ba09f7	fix(tradein/geocoder): темп Nominatim сдерживается перед запросом, а не после успеха (#2953) (#2954)	2026-08-20 07:55:41 +00:00
bot-backend	cf48e6d6c8	feat(tradein): позиция квартиры внутри когорты аналогов — перцентиль (#2899) (#2926)	2026-08-19 10:08:18 +00:00
bot-backend	d0071c57bc	fix(tradein): фильтр выдачи Яндекса мёртв — slug ЖК ищем по странице объекта (#2860) (#2923)	2026-08-19 08:37:40 +00:00
lekss361	215b78a348	Merge pull request 'fix(tradein/estimate): залипший anchor_tier больше не глушит четыре механизма разом' (#2920) from fix/2656-anchor-tier-reset into main	2026-08-17 08:00:33 +00:00
bot-backend	42b0ebe338	fix(tradein/estimate): залипший anchor_tier молча глушил IMV-blend и quarter-index ... Флаг anchor_tier оставался равным anchor_tier_fetched ("A"/"C"), когда якорь фактически НЕ строился — сброс делал только low-conf гейт (#audit-1), но не Tier C corridor-гейт (#1795) и не сама _compute_same_building_anchor, когда она отклоняет кандидата (комплов меньше estimate_sb_min_comps). Дальше по коду залипший флаг читается как «headline построил якорь» и молча глушит IMV/Yandex blend (#651, гейт `anchor_tier is None`) и quarter-index correction (#764 Guard-1a) — притом что радиусный headline их не получал. Замер: 154 из 996 сделок теряют tier-флаг этой правкой, и у всех 154 изменение цены ровно 0.000% — чинится именно залипший ФЛАГ, не ценообразование (баланс метрик бэктеста подтверждает: единственная дельта в baseline — новая канарейка unrecorded_lookup_calls, все остальные метрики побитово те же). - estimator.py: сброс `anchor_tier = None` единой веткой `if anchor is None` после всех трёх гейтов (Tier C / low-conf / _compute_same_building_anchor); display-only IMV-карточка больше не гейтится по `anchor_tier is not None` (иначе терялась в щели «тир добыт, якорь не построен, headline подавлен»). - backtest_estimator.py: quarter_index_lookup/quarter_indexes_lookup в реплее отвечают «промах» (None/{}), если сброс флага открыл путь, которого не было в замороженной фикстуре, вместо падения с RuntimeError; счётчик таких промахов уходит в baseline как unrecorded_lookup_calls (точное целое, канарейка на расхождение реплея с захватом). Заодно пиннится estimate_dedup_analogs_enabled = False внутри replay_fixture (было только в самом гейте) — иначе штатная регенерация baseline (--from-fixture --update-baseline) писала baseline, который тест не совпадал бы никогда. - backtest_baseline.json: перегенерирован штатным путём, unrecorded_lookup_calls=0. Выделено из #2656/PR #2661 — фильтры свежести (scraped_at) в якоре дома и в знаменателе коэффициента выкупа остаются в исходном PR как отдельная, более спорная правка (двигает деньги: знаменатель просаживается на ~1.3% по бакетам).	2026-08-17 10:54:07 +03:00
bot-backend	c66047683c	Merge remote-tracking branch 'forgejo/main' into local/pr2836	2026-08-17 10:41:25 +03:00
bot-backend	e00dcac177	fix(tradein/deactivate): resolve migration 264 renumber collision on merge with main ... fix/tradein-ttl-effective-cap (PR #2907, merged into main while this branch was in flight) already claimed 264/265 for deactivate_stale_avito_cap_mult / deactivate_stale_yandex_cap_mult. Renumbers this branch's 264_seed_deactivate_stale_null_segment_yandex_cian.sql -> 266_seed_... (git mv + _manifest_applied.txt entry moved after 264/265 + self-references in the migration header and in test_deactivate_stale_listings.py's _MIGRATION_264 constant/test names). Merges main's bool-guard (ttl_days/cap_mult reject bool) + CAP_MULT ceiling + per-source cap_mult calibration with this branch's null_segment_only kwarg (explicit `listing_segment IS NULL` predicate, since ANY(:segments) never matches NULL) -- both features apply to the same deactivate_stale_listings() call site in product_handlers.py and the same function signature/docstring in deactivate_stale_avito.py, so every conflict was signature/docstring-level, not logic-level (git already auto-merged the function body correctly since the two features touch disjoint lines below the signature). Also reconciled the module docstring's "known gap" note (main) to reflect that the NULL-segment slice it measured (cian 211 / yandex 523 rows >60d) is now closed by this migration -- novostroyki stays open, unrelated to this branch.	2026-08-15 21:13:41 +03:00