main принёс PR #2751 (ruff-шаг в ci-tradein.yml/backend-tests) параллельно с
fetch-depth: 0 из этой ветки в том же job'е — не противоречат друг другу,
слились автоматически.
Единственное ручное разрешение — _manifest_applied.txt (modify/delete):
main дописал файл, ветка его удаляет. Разрешение — удаление, это и есть
предмет PR: гейт номеров миграций берёт эталон из git (origin/main), а не
из ручного манифеста, который отставал и по построению не мог покраснеть
(#2683, живой инцидент 15.08 — коллизия 264_ между двумя независимыми ветками).
Мониторинг GlitchTip сейчас нем (alerts_projectalert/alerts_alertrecipient
пусты, EMAIL_URL=consolemail:// печатает письма в stdout, аудит на проде
2026-08-15). GlitchTip умеет получателя типа webhook, но шлёт свой Slack-
совместимый JSON без каких-либо заголовков — Telegram Bot API его не
понимает, нужен адаптер.
- app/api/v1/glitchtip.py: POST /api/v1/trade-in/ops/glitchtip-webhook —
принимает issue- и uptime-алерты (структурно одинаковый payload у
GlitchTip 6.1.6, см. docstring), форматирует короткое сообщение
(проект/заголовок/ссылка/время получения) и шлёт через существующий
TelegramClient в отдельную тему алертов. Обрезка под лимит Telegram
(4096 симв.), неизвестная форма payload пересылается как есть с
пометкой вместо 500.
- Auth: GlitchTip не может слать кастомные заголовки (aiohttp.post без
headers=) — переиспользуем TRADEIN_INTERNAL_AUTH_SECRET (#2213) как
query-параметр `secret`, constant-time compare. В отличие от rbac.py
пустой секрет здесь fail-CLOSED (503), это единственный auth-рубеж пути.
- config.py: TELEGRAM_ALERTS_CHAT_ID / TELEGRAM_ALERTS_TOPIC_ID — намеренно
отдельные от TELEGRAM_SUPPORT_*, чтобы алерты не лились в топик клиентов.
- rbac.py: путь добавлен в _PUBLIC_PATHS (фиксированный, без секрета в
самом пути — секрет только в query).
- docker-compose.prod.yml: glitchtip-worker (реально шлёт вебхуки, не
glitchtip-web) переведён на networks: [default, shared] — без этого
tradein-backend не резолвится с его стороны (общей сети не было вообще).
EMAIL_URL был захардкожен как consolemail:// — письма печатались в stdout
и никуда не уходили. Теперь адрес приходит из файла окружения на сервере
(GLITCHTIP_EMAIL_URL), пароль почтового ящика в репозиторий не попадает.
Главное здесь не web, а worker: письма и веб-хуки шлёт celery, а у
glitchtip-worker почтовых переменных не было вовсе. Настройка одного
web-сервиса не дала бы ни одного отправленного письма.
Схема DSN зафиксирована комментарием: для 465 нужен smtp+ssl://, а не
smtps:// — вторая помечена deprecated и включает STARTTLS, с которым
Beget рвёт соединение на 465.
Слияние main принесло собственные Sentry-скрубберы (redact_telegram_bot_token +
stabilize_retry_error_fingerprint) в app/main.py и app/scheduler_main.py — конфликт
разрешён композицией, а не выбором стороны: обработчик перед отправкой в GlitchTip
теперь прогоняет событие через всю цепочку в указанном порядке:
scrub_payment_request_body → scrub_pii_event → redact_telegram_bot_token →
stabilize_retry_error_fingerprint (main.py), и без redact_telegram_bot_token в
scheduler_main.py (тот процесс не держит TelegramClient) — оба канала,
before_send и before_send_transaction, используют один и тот же обработчик.
tests/test_sentry_scrub.py: тесты обеих сторон объединены без потерь — PR-D2
платёжный composed-тест (body-wipe + PII-scrub + token-redaction) и весь блок
RetryError fingerprint-стабилизации из main сосуществуют в одном файле.
Слить актуальный main (билд-раннер #2841/#2869, невалидные индексы #2752,
честный health-check и deploy-status #2841) в ветку очистки CI. Один конфликт
в .forgejo/workflows/deploy.yml: список triggers.paths — main добавил
ops/docker-prune.sh (#2887), ветка добавила auth/** (RBAC roles config).
Разрешено сохранением обоих путей, без потери ни одного триггера.
Раньше listing_segment писался ТОЛЬКО при INSERT в save_listings — строка,
единожды родившаяся с NULL-сегментом (классификатор не сработал на первом
скрейпе), никогда не получала сегмент на повторных сборах, даже когда он
становился определим. Симптом лечила отдельная джоба деактивации
(deactivate_stale_{cian,yandex}_null_segment, миграция 266, PR #2908) — чистит
мусор, но не саму запись.
Добавлен listing_segment = COALESCE(EXCLUDED.listing_segment,
listings.listing_segment) в ON CONFLICT DO UPDATE, и тот же идиом в
reconcile-UPDATE (dedup_hash-drift fallback path) — иначе self-heal был бы
неполным для строк, прошедших через этот путь. COALESCE, а не голый EXCLUDED,
чтобы повторный скрейп без определённого сегмента не затирал уже известное
значение пустым (тот же паттерн, что уже применён для city/kitchen/ceiling).
Тесты: tests/test_listing_segment_upsert_selfheal.py — INSERT-путь,
ON CONFLICT COALESCE (обе стороны), reconcile-UPDATE COALESCE.
Три независимые правки инфраструктурной гигиены прод-VPS, замеренные живьём
2026-08-15 (ssh gendesign, read-only).
1. ops/docker-prune.sh: новая секция снимает зависшие (running, но брошенные)
job-контейнеры Forgejo Actions раннера — три штуки Up 4-8 недель на проде,
docker container prune их не видит (фильтрует только status=exited).
Фильтр по имени — якорь ^FORGEJO-ACTIONS-TASK- (regex, не substring),
сервисные контейнеры (forgejo/forgejo-runner*/gendesign-*/tradein-*/couchdb)
под него не подпадают + explicit-skip как страховка. Возраст — из
docker inspect .State.StartedAt, порог JOB_CONTAINER_MAX_AGE_HOURS (default
24 — CI job столько никогда не идёт). DRY_RUN уже существующий флаг,
переиспользован. Идемпотентно на пустом списке (mapfile + `|| true`).
2. ops/journald-gendesign.conf.example: SystemMaxUse=500M для journald.
Замер: journalctl --disk-usage без прав группы systemd-journal/adm
недосчитывает (показал 174M) — реальный du -sh /var/log/journal = 2.5G,
~80% всех 3.1G /var/log. journald.conf на проде сейчас без лимита вообще.
Установка — руками на сервере (systemd-конфиг вне /opt/gendesign, deploy.yml
его не синкает): инструкция в шапке файла.
3. Caddyfile: убран мёртвый блок status.gendsgn.ru (указывал на
несуществующий uptime-kuma, дёргал ACME раз в 6 часов на staging-эндпоинте).
Заодно убрана dangling forward-ссылка "описан для status.gendsgn.ru ниже" в
комментарии у meraocenka.ru. grep подтвердил: других ссылок на этот хост в
Caddyfile/compose/скриптах не осталось (docker-compose.uptime.yml и README
упоминают — вне scope, стек сам по себе не трогается). caddy validate через
prod-контейнер (stdin, без записи файлов на диск) — конфиг валиден, как и
baseline до правки.
На meraocenka.ru посетитель видел внизу страницы экран проверки доступа из
закрытого контура. Замер на проде: три вызова GET /trade-in/api/v1/me → 404
плюс подтянутый следом клиент чата поддержки.
Причина. Caddy на коротком домене переписывает путь ВНУТРЕННЕ (rewrite, не
redir): посетитель остаётся на meraocenka.ru/, а Next получает
/trade-in/mera-public. Поэтому SSR видит /mera-public и bypass срабатывает, а
после гидратации usePathname() возвращает «/» — путь из адресной строки — и
bypass отваливается. Монтируется GuardedRoute, летит запрос к /me, а на этом
хосте Caddy намеренно не проксирует /trade-in/api/* → 404 → NoAccessScreen.
В шапке RouteGuard прямо стояло допущение «домен/rewrite настраиваются
отдельным PR — на поведение гварда это не влияет, он смотрит на путь». Оно
сломалось ровно в тот момент, когда домен появился; заменено разбором факта.
Правка: четыре коротких адреса публичного домена (/, /oferta, /refund,
/privacy) добавлены в bypass ТОЧНЫМ совпадением, отдельной веткой. Префиксную
проверку для «/» применять нельзя — startsWith("/") истинно для любого пути,
то есть один такой элемент сделал бы публичным всё приложение. Эти адреса
существуют только на публичном домене: на gendsgn.ru их ловит catch-all 404, а
«/» отдаёт server-side redirect на /v2 из next.config, то есть приложение по
этому пути не рендерится вовсе.
Тест на оба инварианта: короткие адреса публичны И закрытый контур (/v2,
/admin/*, /history, /scrapers/*, /login) — нет. Мутация «точное совпадение →
префиксное» роняет два теста из четырёх, проверено прогоном.
Проверено: vitest 33 passed (7 файлов), tsc --noEmit, isolation guard 31 файл.
Повторная проверка /coverage закрыла оба MAJOR из #2894, но выявила три
новых дефекта:
1. Город больше не резолвится из моды listings.city найденной когорты —
эта колонка хранит город SWEEP-контекста скрейпера (миграция 196), не
геокод адреса объявления. Замер на проде: 90/90 строк в радиусе 1000м
вокруг Берёзовского имеют city='Екатеринбург', 74/74 вокруг Ревды —
city='Первоуральск'. Города-спутники из COVERAGE_GREEN/YELLOW_CITIES были
физически недостижимы. Город теперь резолвится детерминированно по
lat/lon запроса — ближайший центроид из статичной константы (8 городов,
рядом с ручкой, не в БД — comment объясняет почему) в пределах 25 км.
city_hint остаётся в схеме (фронт его шлёт для соседних ручек), но чисто
информационный — на порог/статус не влияет.
2. test_max_age_outlier_days_passed_to_sql проверял подстроку, которая
встречается в SQL дважды (count и percentile_cont) — мутация «убрать
FILTER у percentile_cont, оставив у count» проходила зелёной. Добавлен
живой поведенческий тест (вставляет когорту + выброс days_on_market=4000,
проверяет что медиана не сдвигается) — ловит эту мутацию (подтверждено:
median 8→9 при мутации).
3. _live_session() вызывался в pytest.mark.skipif на этапе сбора тестов и
создавал никогда не закрываемый Session, плюс дублировался в теле теста.
Заменено на _live_db_available() (open+close голого connection) для
skipif и pytest-фикстуру live_session с гарантированным close/dispose.
4. Nit: пустая когорта в поддерживаемом городе отдавала status=not_covered
вместе с ненулевым threshold — противоречило докстрингу
CoverageProbeResponse.threshold ("0, когда порог неприменим"). threshold
теперь всегда 0 при not_covered, независимо от причины.
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.
В шапке модуля, в комментарии миграции 264 и в докстринге теста стояло «23 687 из
44 744 avito-объявлений не подтверждались >7 суток» под заголовком «ЗАМЕР НА ПРОДЕ».
Число реальное, но приписано не тому. Перепроверено запросом 2026-08-15:
это ВСЕ источники вместе, и две трети — новостройки, которых оценщик не берёт
(он фильтрует listing_segment IS NULL OR = 'vtorichka'). У самого avito
просроченных строк ноль: 8 663 активных, максимальный возраст 10 суток.
Оставлять это в коде нельзя: следующий человек прочитает «avito раздут вдвое»,
проверит и не найдёт — а заодно потеряет доверие к остальным числам в том же
абзаце, которые верны и сверены с scrape_runs.counters.
Заодно явно записано, чего потолок НЕ делает: он не сжимает пул (0 деактиваций
замерено на всех четырёх джобах), а защищает от разгона пола и от опечатки в
расписании. Настоящий раздутый срез — строки с пустым сегментом, они чинятся
отдельной джобой.
Independent review found two MAJOR defects in POST /api/v1/trade-in/coverage:
MAJOR-1: the probe cohort WHERE clause was missing three predicates present
in estimator._COMMON_WHERE / Tier W (novostroyki guard, geo_precision !=
'city', price_rub > 0) — the free probe could answer "ok" at points where
the paid estimator's own 1000m radius tier sees zero real analogs. Prod
example: 56.868904/60.837955, 2 rooms, 50 m2 gave n_listings=22/status=ok
while the estimator's cohort at the same radius was 0 (all 54 rows were
novostroyki). Added the three predicates verbatim from estimator.py, plus
both a static SQL-text regression test and a real-Postgres integration test
(skip_allowlist.txt, same _live_session() pattern as test_gar_flats_loader)
that inserts novostroyka/geo_precision=city/price=0 rows and asserts they
are not counted.
MAJOR-2: median_listing_age_days was computed from days_on_market, which on
prod is populated almost exclusively by one source (yandex) — thin cohorts
produced a "median" over 1-2 listings. Added n_with_age to the response
(honest count of listings the median is based on); median is now null below
COVERAGE_MIN_AGE_SAMPLES=5, and values above COVERAGE_MAX_AGE_DAYS=365 (near
-certainly dead listings, per prod: 15% of fresh yandex rows exceed 365d,
max 4261d) are excluded as outliers before the percentile is computed.
MINOR: city_hint was trusted at face value and echoed back verbatim — a
client could pass city_hint="Екатеринбург" with coordinates in Серов and get
threshold=8/status=ok. _resolve_coverage_city now prioritizes the SQL
cohort's mode city (ground truth) over the client hint, falling back to hint
only when the cohort is empty (where status is forced not_covered anyway).
Unmatched cities no longer echo the raw client string in the city field.
544 yandex + 224 cian active rows carry listing_segment=NULL (legacy rows
predating migration 011, plus a small trickle that can never self-heal since
the upsert ON CONFLICT never rewrites listing_segment on re-scrape). 94-97%
of them are frozen at ~86 days old, yet the estimator's Tier A (same-building)
and Tier C (micro-radius) anchor queries filter only is_active=true -- no
freshness column -- so these stale asking prices anchor live valuations.
deactivate_stale_yandex/_cian (migration 115) already run at TTL=30 but scope
segments=['vtorichka'] only: `= ANY(CAST(:segments AS text[]))` never matches
NULL, so the NULL bucket was invisible to both existing jobs and to
avito/domklik/n1 (which are source-blanket or vtorichka-only respectively).
Adds null_segment_only kwarg to deactivate_stale_listings() building an
explicit `listing_segment IS NULL` predicate (confirmations/revisit-floor
builders extended in parallel for correctness, though both gates are kept
off for this slice -- population too small for thresholds calibrated on a
full vtorichka sweep, would permanently skip as unhealthy). Two new
scrape_schedules rows (migration 264) run it per source, untouched
novostroyki/vtorichka jobs unaffected.
TTL=60d (vs 30d for vtorichka): revisit-floor is not computable here (rows
out of dedicated sweep scope have no revisit-gap history), so the margin is
folded into the TTL directly -- 2.26x/1.4x over the measured p99 revisit gaps
already on file for cian/yandex vtorichka (26.6d/43.0d). Bimodal age
distribution means this costs almost nothing in coverage (30d vs 60d: 744 vs
734 deactivated).
First run: 734 of 768 NULL rows deactivated (211 cian, 523 yandex), 34 remain
(fresher than 60d, still incidentally re-touched). Comparable pool
(is_active AND segment IN (NULL, vtorichka)) after: cian -2.7% (7739->7528),
yandex -10.2% (5133->4610) -- yandex crosses the 10% flag threshold. All 734
removed rows already had scraped_at frozen >60d, i.e. already excluded from
Tier S/H (which do filter freshness, 14-60d window) -- the drop is real for
is_active headcount but zero-impact there; it only prunes Tier A/C, where it
removes stale prices rather than live comps.
Separate finding (not fixed here): base.py's ON CONFLICT DO UPDATE omits
listing_segment from SET entirely, so a legacy NULL row can never heal even
though cian/yandex SERP always compute segment deterministically on re-scrape.
Три остатка ревью TTL-CAP:
1. cap_mult < 1 пропускал bool: jsonb true -> True < 1 ложно -> потолок =
ttl_days*True = ttl_days -> пол молча отключается без ValueError. Тот же
класс дыры возможен и через ttl_days=true (TTL молча = 1). Оба параметра
теперь явно отклоняют bool ДО числового сравнения; воспроизведено на HEAD
и закрыто тестами (True/False на обоих параметрах).
2. test_avito_prod_floor_is_capped_by_calibrated_cap_mult хардкодил cap_mult=6
как вход -- мутация миграции 264 (6 -> 2) оставляла набор зелёным. Тест
теперь читает cap_mult ИЗ ФАЙЛА миграции regex'ом, ожидаемый результат
(потолок 60) остаётся зафиксированным числом -- дрейф калибровки в SQL
теперь ломает тест.
3. Текст миграции 264 утверждал "yandex 43.0 -> потолок 60, запас есть" по
статическому p99. Живые полы из scrape_runs.counters (08-10..08-15:
75/75/75/39/52/54) и live-замер сегодня (79.2, n=1961) выше потолка 60 --
тот же false-kill класс, что у avito. Откалибровал yandex отдельной
миграцией 265 (cap_mult=3 -> потолок 90, тот же запас ~14%, что у avito),
поправил таблицу в 264 на живые числа и пиннящий тест по образцу avito.
Численный эффект (live-замер 2026-08-15, до и после): next-run deactivated=0
на всех четырёх джобах что до, что после -- ветка по-прежнему НЕ сжимает пул
(avito/cian: живой пол уже ниже потолка, cap не участвует; yandex: 0 активных
строк старше 39 суток вообще, калибровка убирает будущий риск, не текущее
число; domklik: блокирован гейтом здоровья, confirmations 94 < 200). Ветка
остаётся тем, чем и была: защита от опечатки в расписании + калибровка, не
сжатие пула.
4508 backend-тестов зелёные (uv run pytest tests/), ruff чист на изменённых
файлах.
POST /api/v1/trade-in/coverage — до оплаты пользователь видит только n похожих
объявлений в радиусе 1000м и медианный возраст листинга, без единой цены.
Один SQL (радиус GIST + rooms + area ±15% + freshness 14д + тот же дедуп/cap-
канон, что у estimator._fetch_analogs), ноль внешних вызовов, ноль записей.
Пороги ok/thin/not_covered — константы рядом с ручкой (зелёные города >=8,
жёлтые >=12, остальные всегда not_covered). Поле median_listing_age_days
(не "срок продажи" — возраст активного объявления, цензурированная выборка).
RBAC не тронут — путь остаётся закрытым, открытие анонимного периметра
вынесено в #2895.
Ревью round 1 подтвердил basic_auth-часть, но нашёл 4 факта в RetryError-части:
1. reraise=True в geocoder.py не убирает шум, а переименовывает: наружу летит
httpx.HTTPStatusError, чей str() содержит ПОЛНЫЙ request URL с query string
(`for url '...search?q=<адрес>&...'`) — воспроизведено эмпирически. Тот же
per-address issue-explosion, просто под другим типом исключения.
Фикс: _HTTPX_ERROR_URL_QUERY_RE в sentry_scrub.scrub_pii_event режет query
string из httpx-style "for url '...'" сообщений — стабилизирует ТЕКСТ, не
только тип, независимо от того, уважает ли GlitchTip fingerprint-поле.
2. stabilize_retry_error_fingerprint затирал fingerprint целиком по (типу
причины) — RetryError из НЕСВЯЗАННЫХ подсистем с одинаковым типом причины
схлопнулись бы в один issue (geocoder vs scraper_kit оба ловят httpx-типы).
Фикс: culprit = event["logger"] (LoggingIntegration ставит его = имя
модуля-источника logger.exception) идёт первым компонентом fingerprint —
разные подсистемы больше не сливаются.
3. Второй живой источник RetryError, пропущенный round 1 (грепали литерал
"RetryError", не producers): BaseScraper._http_get в packages/scraper-kit —
@retry БЕЗ reraise=True, живой путь через YandexDetailScraper.fetch_detail
(yandex/serp.py и valuation.py переопределяют _http_get без retry — не
затронуты). Оставлен на fingerprint-хук намеренно: detail-URL варьируются
в ПУТИ (offer id), не в query — _HTTPX_ERROR_URL_QUERY_RE их не покрывает,
а добавление reraise=True туда воспроизвело бы ту же проблему через
HTTPStatusError с variable path вместо query.
4. type(exc).__name__ == "RetryError" (string-compare) → isinstance(exc,
RetryError) с прямым импортом tenacity.RetryError — не матчит посторонние
классы с тем же __name__, не промахивается мимо подклассов.
Полный backend suite (4479 passed, 21 skipped) + geocoder/scheduler/alerts
подмножества — без регрессий (reraise=True уже влит в main).
Не тронуто (вне scope round 2, подтверждено ревьюером как верное):
ops/glitchtip-auth-forwarder/* (basic_auth 401 дроп), массовая чистка
накопленных issue.
Round-2 review (MAJOR) left three items open:
1. cap_mult was threaded through as a jsonb default_params parameter but never
validated, reproducing the exact ttl_days<=0 hole the earlier guard closed.
Verified live: cap_mult=0 -> effective_ttl=0 -> whole active pool of the
source would deactivate; cap_mult=0.5 pushes the ceiling BELOW the operator-
configured ttl_days. Added `if cap_mult < 1: raise ValueError` next to the
ttl_days guard (same fail-fast contract, before any SQL). Non-numeric values
(e.g. a stringly-typed "6" from a typo in default_params) already fail safe
via TypeError on the comparison, caught by the same except-block -> mark_failed.
Covered with 5 new tests (zero/negative/<1/non-numeric/mark_failed routing).
2. The mechanical part of cap_mult (parameter + wiring) was merged but never
calibrated for avito on prod -- no migration shipped, so prod default_params
for deactivate_stale_avito still lacked "cap_mult" and ran with the module
default (CAP_MULT=2, ceiling=20d), which is BELOW avito's own p99 revisit gap
(42.1d) and below the observed prod peak (floor=52, three runs 08-10..08-12).
Added data/sql/264_deactivate_stale_avito_cap_mult.sql (idempotent, same
pattern as 219) setting cap_mult=6 for deactivate_stale_avito only (ceiling
60d, matching the order of magnitude already used for cian/yandex). cian/
yandex/domklik keep the CAP_MULT=2 default -- their p99 gaps (26.6/43.0/3.1)
sit comfortably under their default ceilings (60/60/28), no override needed.
Pinned the calibration with a dedicated test
(test_avito_prod_floor_is_capped_by_calibrated_cap_mult) instead of leaving
the avito slice skipped in the false-kill coverage test.
3. Confirmed (SSH read-only, prod counts): active rows aged >60d that this PR
cannot touch regardless of cap_mult -- cian/novostroyki 9483, cian/NULL
211, yandex/NULL 523 (0 inside the jobs' actual scope: cian/vtorichka,
yandex/vtorichka). deactivate_stale_cian/_yandex are scoped to
segments=['vtorichka'] by a deliberate, documented DECISION (blanket TTL on
novostroyki risks killing live inventory cian/yandex don't fully sweep).
Widening that scope is a separate, riskier investigation and is out of
scope here -- documented the gap directly in the module docstring next to
the existing DECISION so it isn't lost.
Verification (SSH read-only against prod, 2026-08-15): recomputed the exact
per-source formula the next scheduled run will use. In-scope next-run
deactivation is currently 0 for all four sources -- the active pool has
already self-corrected to be consistent with each source's own recent
effective TTL (yesterday's yandex run used effective=54, so no active row is
older than that yet). This matches the round-2 reviewer's own conclusion: the
cap is a preventative guardrail, not a retroactive cleanup, and isn't expected
to fire on the exact day it's calibrated. It is not idle, though -- live
recompute of yandex/vtorichka's raw (uncapped) floor right now is 78.2d,
already above its 60d ceiling; the trailing 6-day counters show the identical
loop (floor=75, deactivated=0, three days straight) already recurred twice
without this cap in place. The mechanism will bind the moment the pool ages
past the ceiling, which is exactly the recurrence it exists to stop.
Tests: 106 passed (test_deactivate_stale_ttl_cap.py,
test_deactivate_stale_revisit_floor.py, test_deactivate_stale_health_gate.py,
test_deactivate_stale_listings.py, test_migrations_manifest.py). ruff clean.
scripts/check-migration-lock-timeout.py: pass (UPDATE-only migration, no
blocking DDL, no SET LOCAL needed).
Дизайн-макет владельца (15.08.2026). Собрано рядом с живым лэндингом, а не
вместо него: /mera-public открыт на meraocenka.ru, менять его посреди
согласования дизайна нельзя.
- b2c-tokens.ts — палитра макета отдельно от v2/tokens.ts. Красить теми же
токенами B2B-экран нельзя, это другой продукт; hex-литералы остаются в
одном файле.
- marketing-v3.ts — числа из макета в ОДНОМ месте, с таблицей расхождений
с нашими замерами и гейтом: заменить вычисляемыми до снятия noindex.
- _components/v3/ — шапка с селектором города, подвал, липкая CTA, герой
с карточкой проверки, три шага, «Точность», «Цена ошибки».
- layout.tsx больше не рендерит шапку/подвал: вложенный layout в Next
ДОБАВЛЯЕТСЯ к родительскому, поэтому v3 со своим хромом получал бы две
шапки. Теперь хром выбирает страница — v1 берёт SiteHeader/SiteFooter,
v3 свой.
Отступления от макета (все задокументированы в коде):
- реквизиты и документы берутся из LEGAL_ENTITY, а не из маски
«ООО «МЕРА» · ИНН 66700XXXXX» в макете;
- в подвал добавлены Политика возврата и почта поддержки, которых в макете
нет, — обязательные элементы платного контура;
- бейджи МИР/СБП/VISA не рендерятся: приём платежей не подключён;
- форма не выдаёт результат — анонимного расчёта нет, а одинаковые
«14 объявлений» на любой адрес это обман конкретного человека, а не
продающая формулировка. Ветка результата свёрстана и ждёт /coverage;
- замыленная рублёвая цифра не перенесена: в макете она лежит в разметке
текстом под filter:blur и достаётся из исходника;
- акцент #16A9BC не используется как цвет текста (2,6:1 на фоне страницы) —
для текста затемнённый #0B6B79, 5,8:1;
- города и объёмы в селекторе — из нашего реестра, а не 42 города РФ.
Секции макета, требующие отсутствующих данных и контуров (лента
прогноз→факт, игра, продажа под ключ, статьи, модалка, оплата), не
верстались — заведены задачами #2894-#2904.
Проверено: tsc --noEmit, next lint, isolation guard (31 файл),
next build — /mera-public/v3 пререндерится статикой.
Джоба openapi-codegen-check покраснела на этой ветке: она дампит app.openapi(),
регенерирует frontend/src/types/api-types.ts и падает на расхождении. Добавленный
HEAD /health попал в схему и потребовал правки сгенерированного файла.
Регенерировать типы ради маршрута, который фронт никогда не вызывает, — лишний
шум в generated-коде. HEAD-проба это инфраструктура для uptime-монитора, а не
часть контракта, по которому фронт строит типы, поэтому include_in_schema=False
здесь и по смыслу верно, а не только удобно.
Флаг ставим в обоих бэкендах симметрично: у trade-in codegen-джобы пока нет, но
расхождение схем между двумя бэкендами потом само станет источником вопросов.
Review round 2 on #2626 (local houses fallback) found two HIGH-severity bugs
verified live against prod data:
1. _extract_local_house_token took the LAST digit-like token in the raw
address, so "...Педагогическая, д 15, кв 11" resolved house=11 (apartment
number) instead of 15 -- confidently returning a stranger's building with
confidence='exact', written to geocode_cache. Fixed by stripping the
apartment/office/floor/entrance tail (кв/оф/пом/подъезд/этаж -- NOT
корп/к, which is part of the house number) before extracting the token.
Fixes the exact prod case from the review plus the corpus+apartment
combo ("д 26 к 1, кв 41" -> 26к1, not 41).
2. houses is not an EKB-only table (21% of rows with coords are outside the
metro, some as far as another city) -- "улица Маяковского, 7" in houses
resolves to Серов, not Екатеринбург, and use_local_ekb only gates the
user's query text, not the source row. Added an is_within_ekb_bbox_wide
check on every candidate row before it can become a match.
Also addressed two MEDIUM findings from the same review:
3. The "<номер> -> <номер>к1" corpus guess only checked uniqueness among
к1-labelled rows, so real multi-building addresses (Онуфриева 24: к1/к2/к3,
250-400m apart) resolved confidently to к1 anyway. Guess is now skipped
when any other corpus/slash variant of the same base number exists among
the street's candidates.
4. Houses-fallback results are no longer cached in geocode_cache -- the
source (scraped listings) is less reliable than geoportal/cadastral/
Nominatim, and the lookup is cheap/local, so caching only extended the
lifetime of a possible bad match. Side benefit: address_refined now
survives every repeat request of the same raw address, not just the
first.
Also added ORDER BY address, id to the underlying query so the coordinate
dedup picks a deterministic row (LOW finding #5).
14 new/updated tests in test_geocoder_local_houses_fallback.py cover all
five findings against real prod address/houses-row fixtures. Full geocoder
+ dadata + estimator/pdf regression suite (402 tests) green.
Ревью честного run-status нашло, что _RESULT_COUNTER_KEYS ловил не только целевой
yandex_newbuilding_sweep, но и rosreestr_dkp_import (rows_inserted, 66 из 67 прод-
прогонов = здоровый ноль догнавшего инкрементального импорта) и newbuilding_enrich
(processed — счётчик попыток, ==limit даже при частичном провале). Первое завело бы
практически непрерываемый ложный zero-стрик у здорового источника, второе маскировало
бы реальные отказы под measured-N.
Проверено по прод-БД (2026-08-15): "succeeded" пишут ТОЛЬКО yandex_newbuilding_sweep
(42 прогона/90д) и newbuilding_enrich (65/90д) — ни разу rosreestr_dkp_import; у
yandex_newbuilding_sweep succeeded численно совпадает с rows_inserted на всех 42/42
прогонах. Заменил "rows_inserted"+"processed" на "succeeded" в _RESULT_COUNTER_KEYS
(app-копия и byte-эквивалентная kit-копия) — цель (b) исходной правки сохранена, ложный
стрик у rosreestr_dkp_import снят, попутно newbuilding_enrich получает честное
измерение вместо счётчика попыток.
Также поправлены докстринги test_backfill_honest_status.py — два кейса (76%/72%
отказов -> 'done') проверяют только выбор финализатора mark_backfill_finished
(mark_done там замокан); реальный mark_done с honest-run-status переквалифицирует их
в 'failed' через _failed_ratio_too_high — это не документировалось явно.
Review of 3a1e29a7 found CAP_MULT=2 is uniform across sources with wildly
different ttl_days, so it produces a different ABSOLUTE ceiling per source:
cian/yandex (ttl=30) -> 60d, avito (ttl=10) -> 20d, domklik (ttl=14) -> 28d.
That breaks exactly where the crawl's revisit tail doesn't scale with
ttl_days: avito's measured p99 revisit gap is 42.1d (_REVISIT_TAIL) --
above its own default cap of 20d -- so a legitimately slow-but-alive avito
crawl cycle would get its floor cut below the very tail the floor exists
to protect (the false-kill scenario #2659 was filed for). cian/yandex/
domklik aren't affected: their default ceilings (60/60/28) already sit
comfortably above their own measured tails (26.6/43.0/3.1).
Fix: cap_mult is now a function parameter (same pattern as
revisit_floor_quantile/min_confirmations) with the module constant CAP_MULT
as its default, wired through product_handlers via default_params["cap_mult"]
so a schedule can override it without touching the shared default. Also
closes the ttl_days<=0 edge case flagged in the same review: before the cap,
max(ttl_days, floor) tolerated a misconfigured ttl_days<=0 as long as the
floor was positive; with the cap, min(floor, ttl_days*cap_mult<=0) would
silently defeat that protection and match nearly the whole active pool.
ttl_days<=0 now raises ValueError before any SQL, same contract as the
existing staleness_column whitelist check.
Also verified (read-only, postgres-tradein) the review's core "no-op"
claim: false. scrape_runs.counters for the 6 days since the revisit-floor
went live (08-10..08-15) show the cap DID bind on 3 of 6 runs for avito
(floor 52 vs cap 20) and 3 of 6 for yandex (floor 75 vs cap 60) -- the
reviewer's "no source hits the cap" read a single-day trough right after
a natural recovery, not the whole observation window. See PR discussion
for the full counter history and refutation detail.
Refs #2659
Ревью R2 нашёл, что вся безопасность предыдущего фикса держалась на
недоказанной поддержке act_runner'ом steps.<id>.outcome: если раннер его
не заполняет, retry-шаг молча не бежит, continue-on-error проглатывает
падение сборки, job зелёный — а деплой тянет старый :latest на прод.
- Добавлен engine-agnostic verify-шаг после каждого retry (6 мест,
deploy.yml + deploy-tradein.yml): `docker buildx imagetools inspect
<image>:<sha>` без continue-on-error. Не зависит от того, поддерживает
ли раннер outcome — проверяет реальное состояние registry напрямую.
Если ни build, ни retry реально не запушили образ — шаг падает и job
честно FAILURE независимо от семантики outcome.
- Вернул `cache-to` в retry-шаги (6 мест): без него битый buildcache-тег
никогда не перезаписывался — retry всегда собирал без cache-to, значит
cache-to не выполнялся НИКОГДА, и каждый следующий прогон снова падал
на том же cache-from. Заявленное самолечение не работало ни разу.
- Health-check в deploy.yml (main-стек) под `set -e` не мог упасть:
`curl ... && break` — curl не последняя команда &&-списка, POSIX
освобождает такие команды от errexit, цикл дохаживал до sleep (exit 0)
даже если curl ни разу не отдал 200. Приведено к паттерну
deploy-tradein.yml: явный флаг healthy + `exit 1` после цикла.
Подтверждено локальным bash-репро (mock curl, всегда failure): старая
версия — exit 0, новая — exit 1; позитивный сценарий не сломан.
docker rm -f без -v в SSH-скриптах деплоя не тронут.
Review-разбор ветки fix/tradein-uptime-honest-green:
1. [HIGH] Прод-симптом `HEAD gendsgn.ru/health -> 405` обслуживает Site
Finder (Caddyfile:60 `handle /health { reverse_proxy backend:8000 }`),
а предыдущий коммит правил только tradein-mvp/backend, чей /health наружу
не проксируется вообще. Добавлен @app.head("/health") в backend/app/main.py
рядом с существующим @app.get — эмпирически подтверждено (uv run pytest):
HEAD было 405, стало 200. tradein-mvp фикс не откачен (безвреден, годится
для будущего internal-caller), но обвязан комментарием, что реальный
прод-путь чинится не там.
2. [LOW] Response(status_code=200) без media_type отдавал HEAD без
Content-Type, тогда как GET отдаёт application/json — расходится с
заявленным в комментарии RFC 9110 §9.3.2. Добавлен media_type в обоих
бэкендах; Content-Length сознательно не подгоняем под байты GET-ответа
(payload header field, RFC разрешает опускать для HEAD) — не дублируем
сборку payload ради байт-в-байт соответствия.
Тесты: test_health_head_ok_no_body добавлен в backend/tests/test_health.py
(Site Finder) — RED-check (git stash app/main.py) воспроизводит прод-баг
1:1: assert 405 == 200. tradein-mvp/backend/tests/test_health_endpoint.py
дополнен проверкой Content-Type. uv run pytest — все зелёные.
28/1084 прод-оценок имели lat IS NULL — гарантированный ноль аналогов, клиент
не получал оценку вовсе. Дом уже был в houses (скрейпленные листинги), но не
резолвился ни geoportal/cad_buildings, ни Nominatim: разговорное/усечённое имя
улицы («Онуфриева» вместо ГАР-каноничного «Начдива Онуфриева») или отсутствующий
в вводе корпус («49» вместо реального «49к1»). Добавлен последний тир geocode()
с двумя defensive-допущениями (суффиксный матч улицы + опциональная догадка
«номер+к1») — при любой неоднозначности возвращает None, а не гадает; проверено
живыми прод-адресами (Онуфриева/Хрустальногорская резолвятся, Крестинского
корректно остаётся неоднозначным — два разных дома в houses под одним номером).
Отдельно: HTTP 403 «услуга CLEAN выключена на аккаунте» логировался как ERROR
на каждый /estimate (164 события) — это статичная конфигурация аккаунта, а не
сбой; понижено до WARNING (первый раз за процесс) + DEBUG на повторы, чтобы
ERROR продолжал значить настоящую проблему.
83% of tracker issues (7460 total) were pure noise drowning real signal:
- basic_auth 401 (3738 issues, 2019 distinct titles) — ops/glitchtip-auth-
forwarder sent EVERY 401 from bots scanning gendsgn.ru (GET /wp-admin/
install.php etc.) as an individual GlitchTip event, remote_ip baked into
message/tags inflated cardinality. Not an application error — expected
bot-scan traffic against a basic_auth-protected site.
- RetryError (2462 issues) — geocoder.py's three tenacity @retry-wrapped
Nominatim helpers (lookup/suggest/reverse) raised tenacity.RetryError on
exhaustion without reraise=True; RetryError.__str__() embeds a Future
repr() with a memory address that differs every call, so GlitchTip
grouped each exhausted retry as a distinct issue instead of one.
Fix at the source, not post-hoc issue cleanup:
- forwarder.py: before_send drops events tagged event_type in
{basic_auth_failed, basic_auth_storm}; forwarder's own capture_exception
(real script bugs) carries no such tag and passes through untouched.
- geocoder.py: reraise=True on all three @retry decorators — propagates
the real underlying exception (stable type + stacktrace) instead of the
unstable RetryError wrapper.
- sentry_scrub.stabilize_retry_error_fingerprint: belt-and-suspenders
before_send hook, composed into both app/main.py and scheduler_main.py
(geocoder runs in both processes — FastAPI request path and the
overnight geocode_missing_listings batch). Collapses any RetryError that
still slips through into one persistent issue per cause-exception type
name only — never IP/address/listing-id.
Content-ful categories (OperationalError, city-sweep, harvest_quarter,
cian/avito/yandex sweep failures, scrape_freshness_check — ~700 issues)
are untouched: filters key off event_type tag / exception type name only.
Три прод-факта, где status='done' врал о реальном исходе прогона:
- avito_detail_backfill 15.08: {"attempted":64,"failed":57,"enriched":6,"blocked":1}
-> 'done'. mark_backfill_finished звал mark_done, потому что produced=6 (>0);
ни _sweep_run_did_nothing (нет anchors_total/errors_count у backfill'ов), ни
_phase_totally_failed (голые "attempted"/"failed" без фазового префикса) эту
форму counters не ловили. Новый _failed_ratio_too_high внутри mark_done:
failed/attempted >= 0.5 -> 'failed', >= 0.15 -> тоже 'failed' (другая
формулировка причины в error-тексте) — 'partial' статусом не заведён: это
потребовало бы DROP+ADD CHECK constraint (051_scrape_runs_extend.sql) и
дообучения ещё 4 мест (Literal-фильтр admin API, статусы фронта, оба
IN-списка сторожей) — тот же класс проводки, что и у ban_kind (#2686/#2764),
который сознательно не стал новым статусом.
- yandex_newbuilding_sweep 26.07-10.08: десять прогонов подряд 'done' при
processed=5 succeeded=0 rows_inserted=0 failed_resolve=4-5 — сторож нулевого
результата (_alert_if_consecutive_zero_results) не видел ни один результатный
ключ этого sweep'а и молчал навсегда. _RESULT_COUNTER_KEYS дополнен
rows_inserted/processed (именно в этом порядке — rows_inserted это результат,
processed это попытки; иначе "5 обработано, 0 записано" замаскировалось бы
под measured-5).
- admin-витрина показывала new_count=0 у трёх подряд cian_full_load при реально
сохранённых saved_inserted=482/214/239 — full-load'ы не пишут ни 'new_count',
ни 'lots_inserted'. _column_counts дополнен saved_inserted/rows_inserted.
Правки продублированы в scraper_kit/orchestration/runs.py (byte-эквивалент
app.services.scrape_runs, см. докстринг модуля) для параллели: единственный
текущий писатель "attempted"/"failed" (mark_backfill_finished) живёт только в
app-копии, но приоритет ключей/константы держим синхронными на будущее.
Не тронуто: сознательно пустые sweep'ы (errors_count=0, honest empty) и малые
батчи (attempted < 3) — доля отказов на них не считается диагнозом.
Tests: tests/test_honest_run_status_failed_ratio.py (41 кейс, оба модуля,
включая точные прод-числа из трёх фактов выше) + regression-прогон 609 тестов
по всем файлам, трогающим scrape_runs/orchestration.runs — 0 регрессий.
@app.get("/health") в FastAPI/Starlette не добавляет HEAD-обработчик
автоматически (в отличие от низкоуровневого Route(methods=["GET"])) —
внешний uptime-monитор (GlitchTip PING-тип шлёт HEAD) получал 405 и не
мог отличить "жив" от "мёртв" по статусу. Добавлен явный
@app.head("/health") — 200 без тела (RFC 9110 §9.3.2), GET не тронут.
Тест test_health_endpoint.py фиксирует оба метода; RED до фикса
(HEAD → 405), GREEN после (проверено git stash + повторный прогон).
