Ошибки Telethon почти всегда читаются по шаблону: тип исключения, текст RPC и место вызова. Если видите FloodWaitError — это не баг, а лимит на частоту; если PeerFloodError — аккаунт уже помечен за агрессивные действия; если SessionPasswordNeededError — включена 2FA и нужен пароль, а не повторная авторизация.
Разбор начинайте с контекста запроса: какой метод вызван, какой peer передан, есть ли валидная сессия и не протух ли auth key. UsernameInvalidError, UsernameOccupiedError, ChatAdminRequiredError обычно указывают не на сеть, а на неверные входные данные или отсутствие прав. Здесь логика важнее ретраев. 🔧
Сетевые симптомы выглядят иначе: TimeoutError, OSError, ConnectionResetError чаще связаны с прокси, нестабильным каналом или разрывом TCP. Если ошибка плавает, проверяйте DC, прокси-цепочку, DNS и повторяемость на чистой сессии. Оптимизируем сессии, избегаем лимитов.
Полезная привычка — логировать не только текст ошибки, но и: метод, id чата, время, номер попытки, тип сессии, прокси и результат предыдущего запроса. Тогда один и тот же RPC станет не “хаосом”, а диагностикой. Разбираем логи ошибок: что пошло не так на стороне API?
Telethon мастерская
@telethon_workshops_ubt
Telethon падает не “случайно”: как читать RPC-ошибки и логи Telegram
Этот пост опубликован в Telegram-канале Telethon мастерская. Подписаться можно по ссылке: @telethon_workshops_ubt.