fix(whatsapp): не дать ассистенту молча умирать — токен и реконнект

[ShaerWare]

Что случилось

WhatsApp-ассистент лежал двумя независимыми поломками:

• с 15 августа — отвечал ошибкой на каждое сообщение при живом коннекте;
• с 18 августа — канал отвалился целиком и не поднялся сам.

Обе починены; прод уже восстановлен вручную, этот PR закрывает причины.

1. Внутренний токен бота: 24 часа против недель жизни процесса

Бот-подпроцесс получает JWT один раз, в env, при спавне и не умеет его обновлять. create_session() при этом всегда выдавала admin-TTL в 24 часа (ADMIN_JWT_EXPIRATION_HOURS). Процесс живёт неделями → через сутки каждый запрос к /admin/chat/sessions отдаёт 401, llm_router._ensure_session кидает HTTPStatusError, клиент видит «ошибка». Бридж при этом connected, сообщения принимаются, квитанции о прочтении уходят.

На проде: токен iat 14 авг 20:44 → exp 15 авг 20:44. Ровно +24ч.

Поломку не поймали, потому что мониторится статус коннекта, а не доходимость ответа.

• create_access_token() / create_session() принимают expires_hours
• BOT_INTERNAL_TOKEN_HOURS (env, default 1 год) — для внутренних сессий; человеческий admin-TTL не тронут
• сессии по-прежнему регистрируются в user_sessions → отзыв и аудит работают, рестарт бота ротирует токен
• revoke_internal_sessions() гасит прошлый токен инстанса, чтобы годовые admin-токены не копились при каждом рестарте

Тонкость в ротации: внутренний токен выписывается на admin user_id, поэтому отзыв по user_id вышиб бы админа из браузера, а отзыв по общему user_agent — соседние боты. Теперь user_agent несёт instance_id, и отзыв точечный. Кэш JTI чистится первым: хит в SessionCache короткозамыкает проверку в БД, так что токен, отозванный только в БД, продолжал бы работать до рестарта процесса.

2. Бридж сдавался навсегда после 12 реконнектов

MAX_RECONNECT_ATTEMPTS = 12 при backoff 2s→4s→8s→16s→32s→60s×7 даёт бюджет ~8 минут. 18 августа десятиминутная просадка DNS его сожгла, бридж написал giving up reconnecting, manual start required и остался мёртвым до ручного старта.

Дефект в том, что лимит бьёт только по восстановимым ошибкам: loggedOut и connectionReplaced уходят по раннему return и до этой ветки не доходят, restartRequired сбрасывает счётчик. То есть единственное, что он реально убивал, — транзиентные сбои, от которых сессия восстановилась бы сама.

Теперь реконнект бесконечный, прижатый к максимальной задержке — одна попытка в минуту стоит ничего, а сессия лечится сама, как только чинится сеть. После старого бюджета лог поднимается до warn, чтобы реально залипшая сессия оставалась видимой оператору.

Отдельно, на проде (не в git)

/etc/resolv.conf имел options timeout:1 attempts:1 без резервного резолвера — одна медленная выдача сразу давала EAI_AGAIN (те же ошибки видны в RSS-логах как «Temporary failure in name resolution»). Смягчено до timeout:2 attempts:2 + фолбэк 1.1.1.1, бэкап рядом. Проверено: VPN amn0 не в пути host-трафика, и DNS, и WhatsApp идут напрямую через eth0.

Проверка

• tests/unit/test_bot_internal_token.py — 6 новых тестов, пройдены: TTL-override, неизменность admin-TTL, точечность отзыва по user_agent, чистка кэша только своего JTI
• полный юнит-набор: 244 passed, 2 failed; оба падения (test_dataset_synced.py) воспроизводятся на чистом main — предсуществующие, не из этого PR
• ruff check + ruff format --check чисто, node --check на бридже чисто

🤖 Generated with Claude Code