<b>FloodWaitError — не баг, а сигнал: как не убить аккаунт ретраями</b>

<b>FloodWaitError — не баг, а сигнал: как не убить аккаунт ретраями</b>

FloodWaitError в Telethon появляется, когда API уже ограничил частоту действий. Ошибка не лечится повторным вызовом в лоб: каждый лишний запрос только продлевает блокировку. Правильная реакция — остановить текущий поток, зафиксировать wait и перевести задачу в отложенное выполнение.

Что делать в коде:
— ловить <code>FloodWaitError</code> отдельно от остальных RPC-ошибок;
— брать <code>e.seconds</code> как минимальный срок паузы, без «умного» сокращения;
— сохранять контекст операции: peer, тип запроса, аккаунт, прокси;
— ставить очередь задач, а не крутить бесконечный retry loop.

Антипаттерн один: автоповтор без задержки. Если скрипт сразу шлет тот же запрос, лимит растет, а сессия быстрее уходит в плохой профиль. Для массовых сценариев полезно разделять лимиты по аккаунтам и каналам, иначе один FloodWait тормозит весь пайплайн.

Дебаг здесь важнее «оптимизаций»: логируйте RPC-код, длительность ожидания и последовательность действий. Тогда видно, где именно триггерится лимит — инвайт, парсинг, отправка сообщений или чтение списка участников. Оптимизируем сессии, избегаем лимитов.