6 commits

Author	SHA1	Message	Date
bot-backend	a8fa7364ae	merge(tradein/payments): влить main в feat/tradein-payments-perimeter-hardening ... Слияние 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 сосуществуют в одном файле.	2026-08-15 22:32:28 +03:00
bot-backend	349494a9df	fix(tradein/observability): close RetryError-half of GlitchTip noise fix (round 2) ... Ревью 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.	2026-08-15 20:02:44 +03:00
bot-backend	8fcec9f12e	fix(tradein/observability): stop basic_auth 401 and RetryError GlitchTip noise ... 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.	2026-08-15 18:08:04 +03:00
bot-backend	1f85ef7d4e	fix(tradein/payments): тело нотификации не течёт в мониторинг и аудит, повторы банка не отбиваются лимитом ... PR-D2 платёжного контура МЕРЫ — закрывает утечки до открытия публичных путей (PR-D3/D4), сам ничего не открывает: _PUBLIC_PATHS (rbac.py), Caddyfile, roles.yaml, auth_session.py не тронуты. - sentry_scrub.py: новая scrub_payment_request_body — вырезает event.request.data целиком для /api/v1/trade-in/payments/* (sentry_sdk 2.64 кладёт полное тело запроса в request.data, send_default_pii=False это НЕ гейтит — тот флаг управляет только куками). Плюс расширен _PII_KEYS: customer_email/customer_phone/pan/expdate/cardid/rebillid/token/terminalkey. - main.py, scheduler_main.py, tgbot_main.py (все 3 точки инициализации sentry_sdk.init в проекте) — тот же обработчик проведён в ОБА канала, before_send и before_send_transaction. Мотивирующий инцидент: на соседнем продукте вчера закрыли только error-канал, transaction остался без обработчика вообще. - ratelimit.py: точный путь notify — свой щедрый SlidingWindowLimiter (3000/60с per-IP, идиома support.py) вместо общего лимитера, но НЕ полное отключение — backstop против шторма запросов остаётся, подпись проверяется уже после разбора тела (PR-D3). Только notify, не checkout (тот с сессией). - request_audit.py: notify — в audit skip-набор (defense-in-depth: middleware внешний относительно rbac_guard и читает сырой X-Authenticated-User — спуфнутый заголовок иначе писал бы фальшивые события с атрибуцией admin). - smoke-mera-perimeter.sh: негативные проверки-канарейки — notify/checkout сейчас закрыты 404 (meraocenka.ru, Caddy не проксирует) и 401 (gendsgn.ru, rbac ещё не открыл) с обеих сторон периметра. Тесты: scrub на произвольной глубине + payment-path body-wipe, AST-разбор (не substring — комментарии в этих же файлах сами упоминают before_send_transaction) на проводку обоих каналов во всех точках инициализации, 400 запросов notify без единого 429 + контроль что общий лимитер по-прежнему активен на других путях, notify вне user_events даже со спуфнутым X-Authenticated-User: admin.	2026-08-07 16:17:59 +03:00
bot-backend	b579fa4ced	feat(tradein/tgbot): Telegram support-мост @MERAsupport_bot ... Клиент пишет боту в личку → воркер зеркалит сообщение через copyMessage в топик супергруппы-форума → оператор отвечает реплаем на зеркало → бот доставляет ответ клиенту. Полный лог переписки в Postgres. Отдельный контейнер на long-polling, а не webhook в tradein-backend: не нужно пробивать дырку в auth-middleware (_PUBLIC_PATHS, #2213) и маршрут в Caddy, нулевая внешняя поверхность, падение бота не задевает API. Без aiogram — httpx уже в зависимостях, нужны только getUpdates/copyMessage. Маршрутизация ответа — по topic_message_id: message_id в Telegram уникален в пределах чата сквозь все топики, а все зеркала лежат в одном support-чате, поэтому спутать адресата нельзя. Реплай на шапку/на ответ другого оператора не резолвится (у direction='out' topic_message_id IS NULL) → тихий игнор. Безопасность (найдено ревью, воспроизведено эмпирически): - токен Telegram живёт в PATH URL, поэтому sanitize_url его не режет; утекал в GlitchTip через locals стек-фреймов (include_local_variables по умолчанию True) и через span data HttpxIntegration. Закрыто include_local_variables=False + regex-редактор в before_send (обе формы: /bot<id>:<secret> и голая <id>:<secret>), поверх существующего PII-scrub. - httpx-логгер печатает полный URL на INFO → боевой токен уходил бы в docker logs каждые 30с. Приглушён до WARNING. Надёжность: - kill-switch при пустом токене — idle-блокировка, не exit(0): при restart: unless-stopped выход с любым кодом даёт рестарт-луп. unless-stopped выбран сознательно — только он гарантирует автозапуск после ребута VPS. - stop_grace_period: 120s — дефолтные 10с убивали бы контейнер раньше, чем докрутится long-poll (30с) и отработает drain (100с). - сбой SQL теперь ловится отдельно и делает rollback перед сдвигом offset: иначе сессия в failed-transaction не давала сохранить offset, апдейт переигрывался и зеркалился в топик по кругу. 152-ФЗ: переписка — ПДн, ON DELETE CASCADE по chat_id, удаление клиента одним DELETE. Ретенция — follow-up. Бот не включается автоматически: TELEGRAM_* задаются в runtime-env на VPS, без них воркер штатно висит в idle. Порядок — в DEPLOY.md. Тесты: 51 passed (маршрутизация обоих направлений, дедуп, 403→is_blocked, throttle-окно шапки, redaction токена во всех формах event).	2026-07-16 16:58:53 +03:00
Light1YT	af6278eaee	feat(tradein): enrich GlitchTip SDK init — integrations + PII scrub (#396) (#643)	2026-05-29 09:23:17 +00:00