1543 commits

Author	SHA1	Message	Date
bot-backend	09bdd7888b	fix(tradein/domclick): перезапуск браузера на карточку уничтожал пропуск QRATOR (#3212) ... ДомКлик закрыт QRATOR с proof-of-work: первый запрос отдаёт 401 и заглушку с задачей, браузер её решает, дёргает /__qrator/validate и получает пропуск в куках (qrator_jsid2 + qrator_jsr). Пропуск живёт в cookie jar, то есть в browser context'е — а прод брал каждую карточку в новом контексте, выбрасывая его. Повторная валидация с того же IP получала 403 и страницу bot-mitigation. Замер (прод, прод-прокси, по 6 карточек): общий контекст, одна вкладка 6/6, validate не вызывался ни разу общий контекст, вкладка на карточку 6/6, validate не вызывался ни разу новый контекст на карточку (= прод) 1/6, validate = [304, 403] на каждой боевой путь /fetch с reuse_context 6/6 при 0 перезапусков и 1 контексте Что правится: * снят код-дефолт domclick=1 из #3205: перезапуск процесса гарантированно уничтожает контекст, то есть лечил симптом, который сам же и создавал. Ручка per-provider и domclick как отдельный провайдер остаются; * сброс контекста в бэкфилле был на КАЖДЫЙ блок — стал один раз за прогон. Это и объясняет провал #3193: сброс выбрасывал пропуск, следующий фетч блокировался гарантированно, что снова вызывало сброс. Приёмка тогда дала ровно 1 успех из 10; * снята неверная формулировка «отказ, а не челлендж» из #3204/#3205 — 26 624 байта это РЕЗУЛЬТАТ проваленного PoW, а не статика вместо него. Ошибка вышла из метода: HTML читали на 4.5-й секунде и не смотрели в сеть. Замер 6/6, которым обосновывали #3205, был испорчен: в логах сайдкара после каждой страницы стоит «recycle threshold (1) достигнут, перезапуск браузера». Тесты: два кодировали domclick=1 — переписаны через подставной словарь, чтобы уровень «код-дефолт поставщика» продолжал проверяться, а не исчез вместе с записью. Тест сброса требует ровно одну попытку за прогон. 159 passed (сайдкар), 4972 passed / 37 skipped (backend).	2026-08-29 14:09:23 +03:00
bot-backend	57ec24f364	chore(deps/mera): vitest 2 → 3 — заодно уходит вся dev-цепочка vite/esbuild ... Мажор ради GHSA-5xrq-8626-4rwp (CRITICAL, vitest ≤2.x). Сам CRITICAL к нам неприменим — он про `--ui`, а `@vitest/ui` не установлен и скриптов с `--ui` нет — но держать заведомо непатченный рантайм тестов ради этого рассуждения не стоит: следующий, кто добавит `--ui`, про оговорку не узнает. Побочно закрылось больше, чем планировалось. vitest тянет vite сам, и диапазон у мажора другой: 2.1.9 → vite ^5.0.0 (резолв 5.4.21 → esbuild 0.21.5), 3.2.7 → vite ^5||^6||^7 (резолв 7.3.6 → esbuild 0.28.2). Так что одним мажором: vitest 2.1.9 → 3.2.7 GHSA-5xrq-8626-4rwp vite 5.4.21 → 7.3.6 GHSA-4w7w-66w2-5vf9, GHSA-fx2h-pf6j-xcff, GHSA-v6wh-96g9-6wx3 esbuild 0.21.5 → 0.28.2 GHSA-67mh-4wv8-2f99 OSV по локу: 4 → 1. Остаток — postcss 8.4.31, вендоренный ВНУТРИ next/node_modules; нашим локом не управляется вообще. @vitejs/plugin-react 4.3.4 → 5.2.0 — вынужденно и ровно поэтому: у 4.x peer на vite ^4||^5||^6, семёрка в него не попадает. У 5.2.0 — ^4||^5||^6||^7. В шестёрку не идём: там peer уже ^8.0.0. vitest.config.ts править не пришлось: в нём нет ничего из того, что мажор переименовал или убрал (ни environmentMatchGlobs, ни deps.inline, ни workspace) — только environment/globals/setupFiles/include, которые в 3.x как были. Приёмка (локально, node 26): npm run test 66 passed, 2 failed npm run type-check ok Те же самые 2 падения (LoginPage, ветки 429/401) дают и vitest 2 на этом же локе, и vitest 2 на локе ДО апдейта зависимостей — проверено прогоном в обеих конфигурациях. Это локальный node 26 против node 20/24 в CI, к мажору отношения не имеет. Гейт — CI.	2026-08-29 14:08:05 +03:00
bot-backend	be7d7d0205	feat(mera/b2c): лэндинг v3 доведён до макета 29.08 — лента, игра, два пути, возражения, статьи ... Макет «B2C модуль для МЕРА» (Макс, 29.08) — пять секций, которых превью /mera-public/v3 не имело (его шапка их и перечисляла как отсутствующие): - DealsTickerV3 — бегущая строка «ПРОГНОЗ → ФАКТ»; данные — ТЕ ЖЕ строки, что таблица сверок (PROOF_ROWS_PLACEHOLDER): один будущий контур — один набор реквизита, второй не заводится; - GuessGameV3 — игра «Угадай цену», три раунда со слайдером, сверка «ваш ответ / МЕРА / факт», итог с медианной ошибкой игрока; раунды — GAME_ROUNDS_PLACEHOLDER под гейтом #2904; - TwoPathsV3 — «сами / сделаем за вас»; заявка пути 2 ведёт в Telegram поддержки (формы и договора «под ключ» не существует); - ObjectionsV3 — FAQ «перед оплатой» на нативных details; ответы из выверенной честной копии (content.ts/oferta/refund), макетный ответ про «отметки продавцов» заменён тем, что в продукте есть (Росреестр + снятие с публикации); - ArticlesV3 — тизер «Разборы на данных»; карточки БЕЗ ссылок до появления раздела статей (следующий шард). Решение «модалка → /estimate» (StickyCtaV3) сохранено для всех CTA макета. Гейт noindex↔плейсхолдеры дополнен новыми файлами и GAME_ROUNDS_PLACEHOLDER. Проверено: tsc чисто, next lint чисто, vitest 27 passed, живой прогон игры на dev (раунд → сверка → следующая), полностраничный скрин 1:1 с макетом. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 16:06:56 +05:00
bot-backend	5b5d8eb06c	Merge pull request 'fix(deps/mera): 6 уязвимых пакетов во фронт-локе — пересборка без правки package.json' (#3211) from fix/deps-mera-frontend-cve into main	2026-08-29 11:04:29 +00:00
bot-backend	4e8cf5ab62	chore(ci): node 20 отслужил — рантайм фронтов и оба CI-джоба на node 24 LTS ... Node 20 вышел из поддержки 30.04.2026: security-патчи для него больше не выпускаются, а образ node:20-alpine продолжает собираться и молча уносить это в прод. Node 24 — текущая Active LTS. Меняется ровно major рантайма, больше ничего: frontend/Dockerfile node:20-alpine → node:24-alpine (deps/builder/runner) tradein-mvp/frontend/Dockerfile то же, три стадии .forgejo/workflows/ci.yml node-version "20" → "24" (два джоба) .forgejo/workflows/ci-tradein.yml то же (один джоб) Версия в CI намеренно держится равной major'у из Dockerfile — так было и раньше, комментарии рядом обновлены вместе с числом, чтобы не разошлись. Ни `engines`, ни `.nvmrc` в проекте нет — других мест, где закреплён major, не осталось (проверено grep'ом по Dockerfile/yml/md). Совместимость: next 15.5.24 поддерживает node 20/22/24; sharp 0.35.4 — node ^18.17 || ^20.3 || >=22, prebuild linuxmusl-x64 есть. Приёмка — этот самый CI: джобы фронтов теперь выполняются на node 24, так что зелёный прогон PR и есть доказательство. Локально проверить нечем — на машине node 26, это не тот major.	2026-08-29 14:02:55 +03:00
bot-backend	25bebadca5	chore(deps): три места, где сборка не воспроизводится — лок-призрак, глоб и неприпинованный сайдкар ... Ничего не апгрейдит. Убирает три способа собрать образ не тем, что в репозитории. 1. tradein-mvp/backend/uv.lock — удалён (файл был untracked, в .gitignore с рождения). Мера — uv-workspace, сборка берёт КОРНЕВОЙ tradein-mvp/uv.lock (`context: ./tradein-mvp`, `COPY pyproject.toml uv.lock ./` + `uv sync --frozen`). Лок, созданный `uv lock` из backend/, не читает никто, и он тихо разошёлся с рабочим: на 2026-08-29 в нём pillow 12.2.0, starlette 1.0.1, python-multipart 0.0.29, pydantic-settings 2.14.1, weasyprint 68.1 — пять пакетов с открытыми advisory, которых в реальной сборке Меры нет вообще. Именно он подмешал пять фантомных строк в OSV-скан этой серии. Строка .gitignore остаётся (второй лок не нужен), но теперь с объяснением почему — иначе следующий читатель снимет ignore и закоммитит призрак. 2. backend/Dockerfile — `COPY pyproject.toml uv.lock* ./` + `if [ -f uv.lock ]; then uv sync --frozen ...; else uv sync ...; fi` → без глоба и без фолбэка. Глоб + фолбэк означали: пропал лок — сборка не падает, а молча переключается на резолв «свежайшее из диапазонов pyproject». Образ собрался бы с версиями, которых никто не видел ни в одном PR. Теперь пропажа лока роняет COPY. 3. tradein-mvp/browser/Dockerfile — `pip install "camoufox[geoip]" aiohttp` без единого пина. У сайдкара нет лока вообще, так что любая пересборка (в том числе на несвязанном коммите) тянула свежайший camoufox, а с ним другой playwright — под который НЕ написан sed-патч coreBundle.js в том же файле. Запинено по факту прод-контейнера tradein-browser: camoufox 0.5.5, playwright 1.60.0, aiohttp 3.14.3. playwright явно, хотя и транзитивный (camoufox 0.5.5 → playwright<1.61): патч завязан на конкретную сборку драйвера. Там же переписан комментарий «Апгрейд playwright невозможен — camoufox 0.4.11 pinned»: неверны обе половины. camoufox не был запинен ни на что, а 0.4.11 в проде не стоит с неизвестно каких пор — контейнер сейчас несёт 0.5.5 и playwright 1.60.0. Версии сняты с живого прод-контейнера, наличие на PyPI проверено.	2026-08-29 14:01:14 +03:00
bot-backend	b52ec68aad	fix(deps/mera): 6 уязвимых пакетов во фронт-локе — пересборка без правки package.json ... `npm update --package-lock-only` в tradein-mvp/frontend: package.json не тронут, все диапазоны прежние — обновился только резолв внутри них. OSV по локу: 6 уязвимых версий → 4. Закрыто: sharp 0.34.5 → 0.35.4 GHSA-f88m-g3jw-g9cj nanoid 3.3.17 → 3.3.18 GHSA-2v37-7h3g-55p8 Заодно (без CVE, в тех же диапазонах): next/@next/* 15.5.23 → 15.5.24, js-yaml 4.3.1 → 4.3.2, @tanstack/react-query 5.101.4 → 5.102.8, @typescript-eslint/* 8.66.0 → 8.68.0, rollup 4.62.4 → 4.63.1, @testing-library/react 16.3.2 → 16.3.3, ws 8.21.2 → 8.21.3. Остаток (4) диапазонами не чинится, вынесен в отдельную задачу: postcss 8.4.31 — вендорится ВНУТРИ next/node_modules, нашим локом не управляется; vitest 2.1.9 → vite 5.4.21 → esbuild 0.21.5 — dev-цепочка, лечится мажором vitest 2 → 3.2.6+. GHSA-5xrq-8626-4rwp (CRITICAL) при этом неприменим: @vitest/ui не установлен, скриптов с --ui нет. Приёмка (локально, node 26): npm ci --legacy-peer-deps — 566 пакетов, ok npm run build — ok, весь роут-набор собрался npm run test — 66 passed, 2 failed (LoginPage 429/401) Два падения НЕ от апдейта: те же 2 теста падают ровно так же на СТАРОМ локе (проверено откатом лока + npm ci + прогоном того же файла). Локальный node 26 против node 20 в CI; гейт — CI. Хойстинг в диффе выглядит как даунгрейд, но им не является: picomatch 2.3.2 переехал из micromatch/node_modules/ наверх, а 4.0.5 → 4.0.7 ушёл под tinyglobby/ вместе с fdir 6.5.0. Реального понижения версий нет. NB: npm 12 локально требует --allow-remote=all даже при --package-lock-only (ничего не ставится, только резолв). В CI npm 10 — там ограничения нет.	2026-08-29 13:57:20 +03:00
bot-backend	b9025de666	fix(tradein/domclick): площадка отдаёт одну карточку на процесс браузера, а мы держали один на весь прогон (#3205) ... Замер на проде 2026-08-29. Три независимых запуска camoufox через прод-прокси, идём по карточкам до первого отказа — каждый раз одно и то же: карточка #1 даёт 200 и ~1 МБ с SSR-стейтом, карточка #2 даёт 401 и страницу отказа на 26 625 байт. A/B на восьми карточках: свой браузер на каждую — 4 из 4 успеха, один браузер на четыре — 1 из 4. Прямой выход с сервера и выход через прокси неразличимы (1 из 8 в обоих условиях), то есть дело не в IP. Свежего КОНТЕКСТА не хватает: в контрольном замере каждая карточка бралась через browser.new_page(), в новом изолированном контексте, — и всё равно отказ со второй. Признак живёт на уровне процесса, camoufox генерирует отпечаток при запуске, а не при создании контекста. Отсюда: reset_context (#3118) эту задачу не решает в принципе. Цена перезапуска — 0.6 с (3.5 с только первый, холодный). - PROVIDERS: добавлен "domclick" (+ host-detect). Раньше он проваливался в generic и делил браузер со счётчиком страниц с прочим трафиком — при пороге перезапуска 1 это было бы неверно. - BROWSER_RECYCLE_PAGES стал поставщик-зависимым (_resolve_recycle_pages + BROWSER_RECYCLE_PAGES_{PROVIDER}), по образцу BROWSER_BLOCK_IMAGES_{PROVIDER} из #3185. Код-дефолт domclick=1, остальным прежние 15 — у Авито и Циана узор другой и своего замера под него нет. Отдельно починены ~24 холостых охранника в тестах. Они делали monkeypatch.setattr(server, "BROWSER_RECYCLE_PAGES", 10_000), чтобы запретить перезапуск браузера; после перехода на словарь этот патч перестал на что-либо влиять, и набор оставался зелёным лишь потому, что ни один тест не делает 15 страниц подряд. Теперь патчится _RECYCLE_PAGES_BY_PROVIDER, а сама глобальная константа убрана, чтобы её не патчили снова. Проверено мутацией: при пороге 1 для всех провайдеров падают ровно три теста, которые этот дефолт и проверяют, остальные 155 удерживаются — значит охранники работают.	2026-08-29 13:14:20 +03:00
bot-backend	663f426d4c	fix(tradein/domclick): отказ с кодом 401 классифицировался как причина неизвестной природы (#3196) ... Замер на проде 2026-08-29: страница отказа ДомКлика при HTTP 401 — РОВНО 26 624 байта, байт в байт та же, что снималась 28.08 под кодом 403. Ни PoW, ни QRATOR, ни капчи. Приходит одинаково и с валидной сохранённой сессией (16 куков из domclick_session), и полностью анонимно — значит это не «сессия отвергнута», а WAF-отказ с подменённым кодом ответа. В таблице классификатора 401 не было (403/429 → platform, 5xx → infra), поэтому все три пробы подряд дали ban_kind='unknown' — ровно то, что #3196 и должен был убрать. Механика диагноза при этом рабочая: статус доезжает от page.goto до исключения целым, шов blocked.status = status подтверждён живым 401 на проде. Правка доменная — в _ban_kind_of_block домкликового таска, а не в общей scraper_kit.browser_fetcher.ban_kind_from_status: у других поставщиков 401 обычно значит «наша сессия протухла», это наша сторона, и метка 'platform' там зря запустила бы ротацию IP (#2611).	2026-08-29 12:19:18 +03:00
lekss361	cdcb152d76	Merge pull request 'fix(tradein/scrapers): ABORT-лог называл серию блоков, хотя рвал прогон по доле' (#3201) from fix/3184-abort-log-names-wrong-criterion into main ... Reviewed-on: #3201	2026-08-28 20:27:36 +00:00
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	b37acfe00d	fix(tradein/browser): дефолт block_images для avito вернулся к True — гипотеза не подтвердилась ... #3185 выключил блокировку картинок для avito по гипотезе, что она сама по себе сигналит QRATOR'у. Гипотеза шла от camoufox'ского LeakWarning, а не от замера. Что показали замеры после выкатки: - прямой A/B на сайдкаре — 6/8 успехов с блокировкой против 7/8 без, разница в пределах шума; - прод стал хуже: прогон 5200 (картинки блокировались) — 43/63 карточки при 32% блоков; прогоны 5206 и 5207 (не блокировались) — 2/22 и 2/13 при 91% и 77%. Причинность НЕ доказана: между прогонами через тот же пул прокси прошло ~40 моих диагностических запросов, репутация пула могла просесть от них. Но выгоды правка не показала ни разу, поэтому дефолт возвращается к прежнему поведению. Ручка из #3185 остаётся целиком: BROWSER_BLOCK_IMAGES и BROWSER_BLOCK_IMAGES_{PROVIDER} работают как работали, меняется только код-дефолт (_BLOCK_IMAGES_DEFAULT_BY_PROVIDER теперь пуст). Эффект картинок надо мерить отдельно и на чистом пуле. Тест per-provider-override развёрнут в направление, которое ОТЛИЧАЕТСЯ от дефолта (env=false снимает блокировку): со всеми дефолтами True прежний тест с env=true проходил бы и у функции, всегда возвращающей True. Refs #3185	2026-08-28 22:38:00 +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	1ee3c533ed	fix(tradein/scrapers): сайдкар безусловно резал картинки, а camoufox предупреждал, что за это ловят WAF (#3186)	2026-08-28 17:51:36 +00:00
bot-backend	e685f96107	fix(tradein/scrapers): диагноз блока терялся при схлопывании, а в алерт шла непроверенная причина (#3183)	2026-08-28 17:15:02 +00:00
bot-backend	51027d8b02	fix(tradein/ingest): rosreestr_dkp_import курсор переживает рестарт (#3168) ... last_id жил только в памяти процесса (import_rosreestr_dkp, scheduler.py): heartbeat писал его в scrape_runs.counters каждый батч (комментарий рядом прямо называл это чекпоинтом), но при старте last_id всегда инициализировался литералом 0 — обрыв (деплой/OOM/рестарт хоста) откатывал прогресс и заставлял пере-сканировать источник с начала. Разведка: из пяти backfill-циклов issue (avito_detail_backfill, house_imv_backfill, cian_history_backfill, yandex_detail_backfill, geocode_missing_listings) ни один не имеет этого дефекта — все устроены как WHERE ... IS NULL/NOT EXISTS ... LIMIT, естественно резюмируемы без курсора. Единственный код, буквально описанный в issue (строки/SQL/комментарий), это шестой, не входящий в таблицу backfill — rosreestr_dkp_import. Фикс — _resume_dkp_cursor(db, run_id): - кандидат — последний прогон source='rosreestr_dkp_import'; - резюмится только незавершённый штатно прогон: status running/zombie, либо done с counters.interrupted=1 (SIGTERM-drain — эта ветка раньше считала последующий full rescan штатным поведением, теперь помечает себя как прерванную и резюмится наравне с zombie); - потолок возраста чекпоинта — 24ч, старше — 'checkpoint_stale', старт с 0; - чистый 'done' (полный проход) не резюмится — иначе ON CONFLICT DO UPDATE перестанет ловить правки уже импортированных сделок при следующем проходе. Вердикт и per-batch чекпоинт пишутся через kit_runs.update_heartbeat (merge `counters || :counters`) вместо локального runs_mod.update_heartbeat (полная замена) — иначе resume-вердикт стирался первым же heartbeat'ом батча. Тесты: tests/test_3168_backfill_cursor_resume.py — резюм с сохранённого last_id, резюм после SIGTERM-drain, отказ резюмить чистый done, отказ резюмить протухший (>24ч) чекпоинт, merge не стирает посторонние ключи. Обратимость проверена вручную (временный откат _resume_dkp_cursor красил 6 из 8 тестов).	2026-08-28 01:08:21 +03:00
bot-backend	bdb9b64b03	Merge pull request 'fix(tradein/domclick): исчерпание пула прокси помечалось как отказ сбора (#3118)' (#3174) from fix/3118-domclick-no-proxy into main	2026-08-27 22:03:56 +00:00
bot-backend	ade1a065d6	fix(tradein/domclick): исчерпание пула прокси свипа теперь infra-бан, не отказ сбора ... NoProxyAvailableError поднимается из BrowserFetcher.__aenter__ (_acquire_lease) ДО первого HTTP-запроса, когда пул прокси пуст — это НАША инфраструктура, не блокировка площадкой. У run_avito_full_load/run_cian_full_load/run_yandex_full_load уже есть выделенный except NoProxyAvailableError -> mark_banned(ban_kind='infra'), у run_domclick_city_sweep его не было: исключение проваливалось в общий except Exception внутри SERP-фазы, _scraper_ref оставался пустым, и честный статус ниже видел "0 лотов + errors>0" -> mark_failed("fetch errors — 0 listings") с ban_kind=NULL. Прод-факт: run 5023 (27.08) умер за 51 мс, errors_count=1, ban_kind=NULL — неотличимо от честного отказа сбора площадкой. Добавлен except NoProxyAvailableError перед generic except Exception (порядок важен: класс — подкласс RuntimeError). Обработчик зеркалит avito/cian/yandex: mark_banned + ban_kind_of_exception(exc) (даёт BAN_KIND_INFRA), и сохраняет унаследованный чекпоинт (skip_buckets) вместо потери его на нашем же отказе. Тест test_3118_domclick_no_proxy.py проверен на обратимость: без обработчика падает (mark_failed вместо mark_banned), с обработчиком — проходит.	2026-08-28 00:54:48 +03:00
bot-backend	dc793e8701	fix(tradein/yandex): чекпоинт combo ставился до save_listings, не после ... _on_combo в run_yandex_city_sweep делал done_combos.add(combo_label) ДО вызова save_listings. Отказ save_listings перехватывается (осознанно — одна упавшая единица не должна ронять весь sweep) и логируется, но combo уже был отмечен пройденным и уходил в heartbeat done_buckets. Следующий resume брал skip_combos из done_buckets (членство в множестве — само по себе корректно, не трогал) и пропускал этот combo навсегда: молча, прогон завершался штатно, просто сегмент выдачи не собирался никогда. Тот же инвариант "отмечаем пройденным только после успешного save", что уже есть у страницы в run_avito_newbuilding_sweep (_saved_ok), якоря в run_avito_city_sweep (_anchor_ok) и бакета в run_cian_full_load (_mark_bucket) — применил к combo. Heartbeat пишется в любом случае (и при отказе save тоже), иначе reap_zombies посчитает живой прогон мёртвым. Тесты: test_3170_yandex_combo_checkpoint.py — combo с упавшим save не попадает в done_buckets, успешный (включая пустую выдачу) — попадает. Обратимость проверена: с возвращённым дефектом (git stash) первый тест красный, со снятым — зелёный вместе с существующим test_3074_yandex_ sweep_checkpoint.py (6/6).	2026-08-28 00:48:55 +03:00
bot-backend	5a410687ac	feat(tradein/scraper): чекпоинты для avito_newbuilding_sweep — страница как единица (#3074) ... Последний длинный свип без возобновления: при обрыве прогон начинался с первой страницы, а собранное терялось целиком — save_listings вызывался один раз на весь sweep. Единица возобновления — страница выдачи, по образцу якорей в city sweep. `_paginate_sweep`/`fetch_newbuildings` получили `start_page` (уже собранные страницы не запрашиваются) и колбэк `on_page`, который вызывается только после того, как страница пройдена до конца. Сохранение стало постраничным, номера пройденных страниц копятся в `scrape_runs.counters.done_buckets` мержем через `update_heartbeat`. Два инварианта, без которых фича вредна: 1. В чекпоинт попадает только страница, чьи лоты СОХРАНЕНЫ. Отказ save_listings перехвачен и прогон продолжается, но отметить такую страницу пройденной значило бы, что следующий прогон её пропустит и объявления оттуда не соберутся никогда — молча, потому что прогон завершится штатно. 2. Подхват начинается с ПЕРВОЙ несобранной страницы, а не с max+1. Дыра в чекпоинте возможна ровно из-за п.1, и max+1 перепрыгнул бы её навсегда. Страницы после дыры перечитаются — это дешевле потери и безопасно, повторная запись схлопывается по dedup_hash. Оба инварианта закрыты тестами, которые падают при их нарушении.	2026-08-28 00:10:56 +03:00
bot-backend	c01ec805df	fix(tradein/tgbot): в логе сетевого сбоя не было причины — только пустота после двоеточия ... Замер на проде 27.08: `getUpdates` падает 23 раза в сутки, 14 из них за один час. Ретрай почти всегда чинит с первой попытки, поэтому сообщений не теряется — теряется возможность понять, что происходит: network error (попытка 1/3): — retry через 2s После двоеточия пусто. У httpx.ReadError и httpx.ConnectError `str(exc)` пуст, а тип исключения в строку не попадал. По такому логу не отличить таймаут от обрыва соединения от сброса TLS, то есть 23 события в сутки не дают ни одной зацепки. Сеть при этом цела: сырой TLS до Telegram проходит 6 из 6 попыток за ~0.16s. Тип добавляется к тексту, а не вместо него: на исключениях с внятным сообщением диагностика не должна стать беднее прежней. Оба конца закреплены тестами — с пустым текстом и с непустым. Closes #3156	2026-08-27 21:58:51 +03:00
bot-backend	8cdb195e18	fix(tradein/geocode): бюджет прогона не был потолком — проверялся только между батчами ... `run_geocode_missing_listings` рекламирует `budget_sec` как максимальное время прогона, но проверка стояла после возврата из батча. Внутри батча цикл шёл по всем 200 адресам и часов не смотрел, то есть фактический потолок был `budget_sec + один полный батч`. Замер: прогон 5017 (27.08, `budget_sec=1800`) шёл 3150 с — 175 % бюджета, и вышел не по бюджету, а по дренажу: бюджетная ветка за 52 минуты не выполнилась ни разу. Пока адрес стоил ~1.9 с это терялось в шуме. После общего ограничителя темпа Nominatim (#2953) средняя цена 4.5 с, а на трудном хвосте (tier-1 + до 4 typo-вариантов под паузой 1 с, плюс retry×3) — до 33 с. Полный батч из таких адресов уезжает на ~110 минут поверх бюджета, при окне расписания 06:00–09:00. Дедлайн теперь передаётся В батч и проверяется на каждом адресе. Оборванный батч — штатный исход: `geocode_tried_at` проставлен только у обработанных пар, остальные попадут в выборку следующего прогона. Отдельный флаг `budget_exhausted` нужен потому, что `addresses_total` на оборванном батче равен размеру ВЫБОРКИ (== batch_size) — ветка дренажа `addresses_total < batch_size` не сработала бы, и обёртка крутила бы цикл дальше. Тест на это падает без флага (проверено снятием ветки). Тесты: 5 новых, все три несущие проверки падают без соответствующей правки. 37 passed локально. Closes #3151	2026-08-27 19:10:53 +03:00
bot-backend	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	c1918b404d	test(tradein/avito): тест закреплял отсутствие проводки пула ... `assert_called_once_with(source=..., endpoint=...)` требует, чтобы других аргументов у вызова НЕ БЫЛО. Тем самым тест закреплял ровно тот дефект, который чинит этот PR: браузерный фетчер обязан был строиться без проводки пула, иначе CI краснел. Заменено на проверку вхождения: source и endpoint по-прежнему сверяются, плюс явно требуется наличие proxy_provider/use_pool/environment — то, без чего прогон уходит мимо пула (proxy_lease_id=None, 5 блоков из 5 при здоровом пуле). Прогон: 277 тестов зелёные, ruff чист.	2026-08-27 16:16:26 +03:00
bot-backend	d66a52d492	fix(tradein/avito): браузерный бэкфилл ходил мимо пула прокси ... Ветка browser_mode в avito_detail_backfill конструировала BrowserFetcher без proxy_provider/use_pool/environment. Без них фетчер не кладёт "proxy" в тело POST /fetch, сайдкар берёт свой env-прокси, и прогон уходит мимо пула целиком: ни выбора узла по affinity, ни учёта scrape_proxy_source_bans, ни ротации при блоке. В логе это ровно `proxy_lease_id=None`. Ровно этот дефект чинили рядом — #2698 в house_imv_backfill, где он держал 35 отказов из 35 попыток в каждом прогоне полтора месяца, пока соседние свипы через ТОТ ЖЕ сайдкар тянули сотни объявлений. Здесь он остался. Замер 27.08, прогон 5098: mode=browser, proxy_lease_id=None BLOCKED #1..#5 подряд — firewall/soft-block (browser-mode) ABORT — 5 consecutive blocks, enriched=0 attempted=5 При этом пул здоров — 4 узла, все ok, ни один не занят, браузерная проверка пройдена в то же утро. А тот же URL Авито через прокси отдаёт 200 и 3.3 МБ страницы. То есть площадка нас пускала, запрос шёл не оттуда. Это объясняет, почему предыдущая правка (#3143, прокси в повторах curl-пути) не восстановила сбор: боевой режим бэкфилла — browser, и он до curl-веток вообще не доходит. Три теста: конструктор на месте (страховка от проверки пустоты), все три аргумента проводки передаются, use_pool читается из конфига а не зашит константой (зашитый True отнял бы у владельца выключатель, зашитый False вернул бы дефект незаметно). Проверил красноту на коде без проводки. Прогон: 113 тестов зелёные, ruff чист. Refs #3045, #3034, #2698	2026-08-27 15:58:26 +03:00
bot-backend	26cd8dbe34	fix(tradein/avito): повтор после блока терял прокси и уходил с адреса машины ... Обе ветки повтора в `fetch_detail` — 403/firewall и 429 — пересоздавали эфемерную сессию вызовом `_build_detail_session()` БЕЗ `config`. Прокси kit-версия читает только из `config.scraper_proxy_url`, поэтому такая сессия уходила напрямую. Замысел ветки прямо обратный, он записан в её же комментарии: «эфемерная свежая сессия (новый CONNECT-туннель = свежий exit-IP)». Ветка вообще исполняется только при backconnect=True, а он вычисляется как «задан config.scraper_proxy_url» — то есть в момент вызова достоверно известно, что прокси есть, и он терялся. ПОЧЕМУ НЕ БЫЛО ВИДНО. Пока адрес самой машины не был заблокирован, прямой повтор часто срабатывал, и подмена канала выглядела как успех. Замер 27.08 из прод-контейнера, один и тот же URL Авито: через прокси — 200, 3.3 МБ страницы напрямую — 429, «доступ ограничен», firewall С этого момента каждый повтор после блока обречён. Обогащение avito_detail_backfill по суткам: 21-25.08 — 178/129/147/138/111, 26.08 — 23, 27.08 — 0 при 25 блоках. Обвал начинается ровно с окна, в котором сменился адрес машины. Тот же класс ошибки чинили в #2330 для build_warmed_session; в пути повтора он оставался. Три теста: обе ветки на месте (страховка от проверки пустоты), ни одна не строит сессию без config, и отдельно доказано, что без config прокси в сессии действительно нет. Проверил красноту на старом коде — падает с точным текстом. Прогон: 107 тестов scrapers зелёные, ruff чист. Refs #3034, #3045	2026-08-27 15:33:29 +03:00
bot-backend	ede5653aba	feat(tradein/domclick): чекпоинты для city_sweep — корзина как единица возобновления (#3118, #3074) ... Прод-факты #3118: QRATOR рубит свип внутри 1-2-й корзины при любом старте (buckets_completed ≤ 1 из 6), banned-прогоны собирают 59–1815 лотов. Сдвиг #2854 лишь распределяет потери; чекпоинт превращает случайную ротацию в систематический обход — шесть прогонов закрывают шесть корзин. Моё раннее «домклику чекпоинтить нечего» (замер в #3074 по средним 3 мин) опровергнуто данными #3118 — этот коммит исправляет тот вывод кодом. Зеркально yandex-чекпоинту (#3074): провайдер — skip_buckets + имена завершённых корзин + гард «цепочка накопила все 6» (честный no-op); buckets_total сжимается до объёма ЭТОГО прогона; пайплайн — done_buckets = унаследованное ∪ завершённое, heartbeat с мержем jsonb до финализации; планировщик — generic _pick_resume (#2845). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 16:52:44 +05:00
bot-backend	1dcddec9e1	fix(mera/v2): плашка версии лежала на главной кнопке и съедала клик ... Замер на проде 27.08 (окно 1512×900): плашка стояла в левом нижнем углу (`left:16; bottom:16`), а туда же приходит липкая кнопка «ОЦЕНИТЬ КВАРТИРУ» из панели параметров. Прямоугольники: кнопка 59…484 по X и 859…904 по Y, плашка 16…284 и 859…884 — перекрытие по всей высоте плашки. Следствий два, и второе хуже первого. Надпись на кнопке читалась разорванной. И `document.elementFromPoint` в центре кнопки возвращал плашку: клик по левой трети главного действия продукта не доходил до кнопки вообще. Плашка переезжает в правый нижний угол, НАД кнопку поддержки (44px от низа, z-index 25). Там свободно: ниже только пассивная «Сводка объекта» без органов управления — перекрыть её краем ничего не стоит. Вдобавок плашка становится сквозной для указателя, а ссылка «История версий» внутри — нет. Это страхует от повторения: что бы под плашкой ни оказалось в будущем, клик достанется ему, а не ей. Три теста закрепляют оба следствия разбора: якорь не левый, указатель проходит насквозь, ссылка жива. Прогон: 68 тестов зелёные, tsc чист.	2026-08-27 14:37:05 +03:00
bot-backend	e85cafd9a9	fix(mera/b2c): подсказка дублировала адрес, а числа в результате спорили ... Оба дефекта найдены проходом клиентского пути на проде 27.08. ПОДСКАЗКА АДРЕСА печатала одно и то же дважды. Строка списка состоит из главной строки (`label`) и пояснительной (`full_address`), но подсказчик для дома отдаёт их совпадающими буква в букву — проверено на проде: {"label":"Свердловская область, г. Екатеринбург, ул. Малышева, д. 51", "full_address":"Свердловская область, г. Екатеринбург, ул. Малышева, д. 51"} Человек видел адрес продублированным в каждой строке выпадающего списка. Показываем вторую строку только когда она отличается: замысел (короткое имя сверху, полный адрес под ним) сохраняется, если подсказчик когда-нибудь начнёт их различать. ЧИСЛА В РЕЗУЛЬТАТЕ спорили друг с другом. Плитка сверху: «30 похожих квартир продаётся в радиусе 1 км». Плитка под ней: «столько в среднем висит объявление из этих 6». Слово «этих» указывает на 30, а стоит рядом 6 — читается как ошибка в расчёте. Шесть — это те объявления, у которых известна дата публикации; медиана считается только по ним. Теперь доля названа явно («дата известна у 6 из 30»), а когда известна у всех — не упоминается вовсе, чтобы «30 из 30» не шумело. Честное имя величины сохранено: это возраст активного объявления, а не срок продажи (тест на это как был, так и остался). Проверено: 27 тестов mera-public зелёные, tsc --noEmit чист.	2026-08-27 14:29:19 +03:00
lekss361	01b36f623e	Merge pull request 'fix(tradein): срок жизни оценки 24ч → 720ч — отчёты исчезали раньше, чем ими успевали воспользоваться' (#3133) from fix/tradein-retention-720h into main	2026-08-27 10:51:15 +00:00
lekss361	88e23c12a5	Merge pull request 'fix(tradein/auth): лимит попыток входа 5 → 20 на адрес — офис за одним NAT запирал сам себя' (#3132) from fix/login-rate-limit-office-nat into main	2026-08-27 10:51:09 +00:00
lekss361	f9477b1c84	Merge pull request 'fix(mera/ui): карта перестала перекрывать интерфейс, страница помещается в окно' (#3131) from fix/mera-ui-stacking-and-fit into main	2026-08-27 10:51:01 +00:00
bot-backend	0231338a7f	fix(mera/ui): карта перестала перекрывать интерфейс, страница помещается в окно ... Три правки, две причины — обе найдены прогоном по живому проду 27.08 под аккаунтом админа. ## Карта поверх всего (два симптома, один корень) Контейнер мини-карты в HeroBar имел position: relative БЕЗ z-index. Такой блок контекст наложения не создаёт, поэтому внутренние слои Leaflet (тайлы 200, оверлеи 400, маркер 600, атрибуция 800) и карточка адреса (750) конкурировали не между собой, а со всей страницей. Отсюда: • меню аккаунта (UserMenu, z-index 200) открывалось ПОД картой; • карточка «АДРЕС» всплывала поверх таблицы раздела «Продажи в доме». Лечится изоляцией контейнера (isolation: isolate), а не гонкой чисел: перебивать 800 у атрибуции пришлось бы в каждом новом элементе, и гонка возвращалась бы. Меню шапки заодно поднято до 1000 — оно обязано быть сверху по замыслу, а не по совпадению. ## Страница не помещалась в окно Масштаб артборда 1536×1024 считался от window.innerWidth, который ВКЛЮЧАЕТ вертикальную полосу прокрутки. На рабочей области 1425px артборд выходил 1440px — страница получала постоянный горизонтальный скролл. Воспроизводится на любом десктопе: страница длинная, вертикальная полоса есть всегда. Считаем от document.documentElement.clientWidth. Пороги isMobile/ isSmallViewport намеренно оставлены на innerWidth: это классификация устройства, а не расчёт геометрии.	2026-08-27 13:42:56 +03:00
bot-backend	49683b7800	feat(tradein/db): дроп дублирующего listings_geom_idx — geography-двойник несёт всю работу (#2997) ... Критерий (размечен 21.08 ДО окна) выполнен, окно склеено через переезд: замороженный Beget — 4 116 сканов против 217 712 у geog за всю историю (прирост +164/4д — вырожденные IS NOT NULL-планы, паттерн #3020); живой Poincare — 0 сканов за двое суток; EXPLAIN горячего пути — geog; свип кода — ни одного пространственного оператора по голому listings.geom. Экономия 115 МБ + минус одна индексная запись на каждый не-HOT апдейт (их 20.86 млн). CONCURRENTLY по образцу 270, идемпотентно, откат — CREATE INDEX CONCURRENTLY (в шапке миграции). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 15:41:27 +05:00
bot-backend	34f8f506c0	fix(tradein): срок жизни оценки 24ч → 720ч (30 суток) — отчёты исчезали раньше, чем ими успевали воспользоваться ... 27.08, пилот «Практика». У пользователя ВСЕ 75 оценок оказались недоступны, включая позавчерашние: список показывал их со статусом «устарел», а открытие отдавало «Ссылка устарела, отчёт удалён или у вас нет к нему доступа». Выглядело как пропажа данных — на деле строки целы, истёк expires_at = created_at + 24ч. Совпадение двух вещей и создало впечатление аварии: сутки не работал вход (упало право CONNECT на базу auth), и ровно за это время истекли последние живые отчёты. Люди зашли и увидели, что не открывается ничего. Обоснование «оценка живёт сессию клиента, не архив» писалось под анонимный B2C. «Практика» — пилот-юрлицо: менеджер возвращается к оценке через день-два, когда клиент перезванивает. Суточный срок для такого сценария означает, что работа исчезает раньше, чем её успевают использовать. Настройка одна на оба контура, и это осознанно НЕ маскируется: юридический мотив 152-ФЗ относится к анонимному B2C, разделение сроков по контурам — отдельная задача. Здесь поднят общий срок, а не сделан вид, что контуры уже разведены.	2026-08-27 13:31:40 +03:00
bot-backend	b9654d01c0	fix(tradein/auth): лимит попыток входа 5 → 20 на адрес — офис за одним NAT запирал сам себя ... 27.08, инцидент с пилотом «Практика». После починки доступа к базе auth сотрудники начали получать «Слишком много попыток» — при том, что многие ещё вообще не пробовали войти. Причина в форме лимита, а не в его величине. Пилот — ОФИС: все выходят из-под одного NAT, и пять попыток за пять минут делились на всю компанию сразу. Одного человека, перепутавшего пароль, хватало, чтобы запереть остальных. Защита от перебора не ослабевает. Настоящий предохранитель — счёт по ЛОГИНУ (login_username_fail_threshold, 20 за час), он не тронут. Лимит по адресу существует против всплеска с одной машины, а не против офиса, и двадцать попыток за пять минут эту роль выполняют.	2026-08-27 13:26:44 +03:00
bot-backend	3c315b5105	fix(tradein/scheduler): boot-reap виден и при нуле — молчащий механизм неотличим от неподключённого (#3122) ... Первая живая приёмка #3122: деплоевский startup-reap успел снять зомби раньше, boot-reap отработал с нулём — и не оставил НИКАКОГО следа исполнения. Ноль — штатный исход, но «сторож, молчащий при нуле» — это слепая зона по построению: оборванную проводку не отличить от чистого прода. INFO-строка при нуле, warning при снятых — как было. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 14:33:06 +05:00
bot-backend	63956f0891	feat(tradein/scheduler): boot-reap — прогоны предыдущего контейнера снимаются на старте (#3122) ... Прод-факт 27.08 (после ночного офлайна #3119): 4 прогона 'running' со стартами до старта контейнера блокировали свои источники через has_running_run до 6-часового порогового reap'а — до пяти часов слепоты на источник ровно после простоя, когда догон нужнее всего. Критерий — started_at < старт процесса планировщика (минус минута на дрейф), пульс не участвует: ложные срабатывания класса #2702 (редкий пульс длинных прогонов) невозможны по построению — живой прогон этого процесса не может быть старше самого процесса. Маркер counters.boot_reaped=true открывает boot-зомби подхват чекпоинта (_resume_decision): у порогового zombie процесс может быть жив (движущаяся точка — причина исключения 'zombie' из _RESUME_STATUSES), у boot-зомби — гарантированно мёртв. Пороговый zombie без маркера по-прежнему отвергается (закреплено тестом-инвариантом). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 14:17:42 +05: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	8a4215fe20	Merge pull request 'feat(tradein/geo): реестр регионов — единственный источник гео-границ (#3051, шард 1a)' (#3116) from feat/3051-region-registry into main	2026-08-26 15:23:59 +00:00
bot-backend	68daac2a30	feat(tradein/scraper): чекпоинт по якорям для cian_city_sweep (#3074) ... Третий шард после yandex (#3098) и avito (#3112). Выбран по замеру за 60 дней: 65 прогонов, среднее 35 минут, максимум 72, две отмены деплоем. Пятиминутного дренажа (#3029) на такие прогоны не хватает - убитый на 35-й минуте сбор начинался заново с первого якоря. Ключ чекпоинта - ИМЯ якоря, а не индекс: состав списка зависит от city_slug (областные свипы идут по своим наборам), позиция между городами не устойчива. По той же причине гарда по числу якорей не нужна - в отличие от combo-чекпоинта яндекса, где ключ якоря не содержал. Отличие от avito-шарда: там успех и неудача якоря сходились в одной строке и потребовался отдельный флаг _anchor_ok. У циана граница уже проведена самим потоком управления - все ветки отказа делают return или continue и до записи чекпоинта не доходят. Добавлять флаг значило бы дублировать то, что уже выражено структурой; достаточно писать чекпоинт в единственной точке успеха. Тест сторожит эту границу отдельно, потому что рефакторинг, сливающий ветки, сломал бы её незаметно. Пропущенный якорь двигает anchors_done - чтобы счётчик продолжал означать "докуда дошли по списку", а не "сколько собрал именно этот прогон". Тесты (4) поведенческие, с подменой CianScraper и save_listings: якорь из чекпоинта не опрашивается вовсе; пройденный дописывается поверх унаследованных; без чекпоинта обходятся все; упавший в чекпоинт не попадает. Двойнику пришлось добавить счётчики state_extraction_* - конвейер читает их после каждого якоря (#2625), и без них падал бы сам двойник, а не проверяемая логика. Фальсификация: на исходном коде краснеют все 4. Весь набор #3074 (yandex, avito, cian, claim) - 14 passed.	2026-08-26 17:21:58 +03:00
bot-backend	24369a6bf2	test(3051): tests/services/test_location_index.py переведён на _covered_region ... CI поймал то, что мой локальный прогон пропустил: сьют в ПОДДИРЕКТОРИИ tests/services/ звал удалённый _in_ekb_bbox. Граничные точки сохранены те же (продукт-ядро 66 байт-в-байт), проверка дополнена кодом региона. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 18:47:29 +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	7a5997b059	test(2656): краснота на main — по значению, не ImportError ... getattr вместо прямого импорта LISTINGS_FRESH_DAYS из config: на origin/main константы там ещё нет, и тест умирал ImportError'ом на сборке модуля — «возможности нет» вместо «значение неверно». Теперь на main: 5 красных ассертами (предикат отсутствует/окно None/протухшие комплы в пуле), 3 зелёных (сброс anchor_tier уже влит отдельно). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 18:25:54 +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