investigation: теряется ли проактивная защита от флуда при рестарте воркера — замер до фикса

[axisrow]

Наблюдение

Реактивное состояние флуда персистентно: accounts.flood_wait_until
(src/database/schema.py:9), пишется в pool_flood.py:241-246, читается
на каждом выборе аккаунта (account_lease_pool.py:188-191). Переживает рестарт.

Проактивное состояние — только в памяти:

Механизм	Хранилище	Файл
TelegramRateLimitGate	self._limiters — обычный dict	rate_limit_gate.py:141
FloodCircuitBreaker	self._breakers — обычный dict	flood_breaker.py:124
ResolveRateLimiter	deque в памяти	rate_limiter.py:66

Рестарт воркера обнуляет все три. Формально это означает, что после перезапуска
процесс стартует с чистым окном и может немедленно выдать полный залп, а автостоп
(3 флуда → пауза 300 с) забывает уже накопленные срабатывания.

Грепом подтверждено: вопрос перезапуска в этих файлах вообще не обсуждается —
ни слова о restart/персистентности в комментариях. То есть это не осознанный
компромисс с обоснованием, а слепое пятно.

⚠️ Сначала замер, только потом фикс

Это issue НЕ на реализацию персистентности. Сначала надо доказать по данным,
что проблема реальна, иначе это фикс из головы — ровно то, чего проект избегает
(принцип: калибровать замером, а не догадкой).

Что померить по data/app.log и логам рестартов:

1. Как часто воркер вообще перезапускается в реальной эксплуатации.
   Если раз в неделю — проблема умозрительная, и issue закрывается как
   «не подтвердилось».
2. Случались ли флуды в первые секунды после старта — то есть реализовался
   ли сценарий «забыли окно → сразу залп». Искать корреляцию отметок старта
   процесса и всплесков Flood wait.
3. Терялось ли состояние автостопа в момент, когда оно было нужно — то есть
   был ли рестарт между накопленными флудами на одной паре (операция, телефон).
   Это наиболее опасный сценарий: автостоп существует именно против серии,
   приведшей к бану на 14.8 ч (flood_breaker.py:10-14 — 85 флудов за сутки).

Если замер подтвердит — тогда решать как чинить

Варианты (не выбирать заранее):

• Персистить только состояние автостопа (самое ценное, самое редко меняющееся),
  оставив окна лимитера в памяти.
• Персистить всё через существующий механизм настроек — прецедент есть:
  resolve-backoff уже персистится в settings JSON (resolve_guard.py:255-300),
  включая миграцию старого формата.
• Ничего не персистить, но при старте применять «прогревочную» паузу.

⚠️ PyrateLimiter с его SQLiteBucket не подходит: синхронный, ведёт свой
sqlite3.Connection мимо Database._write_lock (правило проекта из #569 —
все записи только через db.transaction() / db.execute_write()).

Acceptance Criteria

• Замер выполнен и приложен: частота рестартов, наличие/отсутствие корреляции
  «старт → всплеск флудов», случаи потери состояния автостопа.
• Явный вывод: проблема подтверждена или опровергнута. Опровержение —
  полноценный результат, issue закрывается без кода.
• Если подтверждена — отдельное решение о способе, согласованное с владельцем
  (правило epic: замена самописного кода на battle-tested библиотеки (реестр находок + решений) #782: замена/подключение обсуждается заранее).
• Никакой реализации до вывода замера.

Файлы

• src/telegram/rate_limit_gate.py:141 — _limiters
• src/telegram/flood_breaker.py:124 — _breakers, :220 — reset
• src/telegram/rate_limiter.py:66 — ResolveRateLimiter
• src/telegram/resolve_guard.py:255-300 — прецедент персистентности через settings
• data/app.log, логи рестартов воркера

Контекст

Часть Phase 2 эпика #1331. Обнаружено при редизайне #1416.
Отдельно отмечено исследователем: чинить только после замера, иначе фикс из головы.

[axisrow]

Замер выполнен — проблема подтверждена. Полный отчёт: tcf-1419-flood-report.md в корне worktree воркера (session tg_content_factory-89). Метод: код-анализ + лог data/app.log (2026-06-12…09-01) + воспроизведение на реальном telethon-floodgate 0.1.0 с инжектным временем, без живого Telegram.

Уточнение к тексту issue: src/telegram/rate_limit_gate.py и flood_breaker.py больше не существуют в репо — стек переехал в PyPI-пакет telethon-floodgate (#1432, шимы снесены #1434). In-memory dict/deque там те же, суть не изменилась.

R1 — рестарты штатны: 27 стартов / 71 день; 21 промежуток < 24 ч (медиана 0.8 ч); 17 июня — 9 рестартов за 4.5 ч.

R2 — «забыли окно → залп»: 1109 реальных флуд-событий; 12 из 27 рестартов (44%) дали флуд в первые 60 с при базовой вероятности ≤2.4% для случайной минуты (~19× обогащение); в +5 мин — 15/27.

R3 — автостоп теряется: все 39 breaker-OPEN в логе — с тест-телефонов (breaker развёрнут 26–27.08, после инцидента). Но 18 стриков по ≥2 флуда на одной паре (операция, телефон) оборваны рестартом — счётчик обнулялся на полпути к порогу 3. Кейс 26.08 (эпоха до breaker'а, базовый ущерб): 83 флуда за 26 ч, 4 рестарта внутри активной серии, финал — Flood wait 53123 s (14.76 ч).

Repro на пакете: рестарт при сжёгнутом бюджете history возвращает +450 вызовов (600/60 с) в ту же секунду; максимальный залп всех категорий — 656 вызовов в секунду 0; breaker с 2/3 накопленных флудов после рестарта требует 3 новых флуда (итого 5); активная пауза 300 с стирается мгновенно.

Уже персистится (не предлагать заново): accounts.flood_wait_until (БД), resolve-backoff + ramp-up (settings JSON), факт полного sweep в dialog_cache — startup-прогрев пропускается, это прямой фикс прошлого «67 прогревов/сутки → бан».

Вывод: разовый рестарт стоит ≤5 минут защиты (окна 60–300 с); опасный вектор — breaker при рестарт-циклах и серии флудов через границы рестартов. Для фикса приоритет — персистентность breaker-состояния (прецедент схемы — settings JSON resolve-backoff; PyrateLimiter/SQLiteBucket по-прежнему нет из-за #569). Окна gate (60 с) дешевле закрыть прогревочной паузой на старте. Реализация — отдельное согласование способа.