Ошибки Telethon читаются не по тексту, а по контексту RPC и логам сессии

Ошибки Telethon читаются не по тексту, а по контексту RPC и логам сессии

Telethon часто прячет корень проблемы за коротким сообщением. Смотри не только на exception, но и на тип запроса: отправка сообщения, инвайт, получение сущности, работа с каналом — у каждого свой набор лимитов и отказов.

Разбираем логи по слоям:
— FloodWaitError: это не баг кода, а лимит на частоту запросов. Считай паузу обязательной, а не «рекомендованной».
— PeerFloodError: аккаунт уже помечен как рискованный для массовых действий. Менять надо не только задержки, но и профиль поведения.
— AuthKeyUnregisteredError или SessionRevokedError: сессия мертва, не лечится ретраями.
— ChannelPrivateError, ChatAdminRequiredError, UserNotMutualContactError: проблема не в API, а в правах доступа или состоянии объекта.

Полезная привычка — логировать request, peer, текст исключения и время ответа. Тогда видно, где ломается цепочка: на резолве юзера, на отправке, на join или на чтении истории. Без этого любая «автореподключалка» превращается в генератор ложных выводов.

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