Ошибки Telethon читаются не по коду, а по месту сбоя: слой, RPC и контекст
В Telethon одна и та же проблема может выглядеть по-разному: FloodWaitError, PeerIdInvalidError, AuthKeyUnregisteredError. Не хватайтесь за код ошибки в вакууме — сначала смотрите, на каком шаге упал запрос: авторизация, доступ к чату, отправка сообщения, инвайт, загрузка медиа.
Логи Telegram полезно читать как цепочку: invoke → ответ сервера → исключение Telethon. Если в трассировке есть RPCError, это не «поломка библиотеки», а отказ API на конкретный метод. Если ошибка повторяется на разных аккаунтах и прокси, проблема обычно в параметрах запроса или в ограничениях самого метода.
Разбираем типовые классы: FloodWait — лимит по частоте, нужен backoff; PeerFlood — сигнал на массовые действия, автоматический рестарт тут не лечит; ChannelPrivate и ChatWriteForbidden — права и доступ; SessionRevoked — сессия мертва, ее надо пересоздать. Дебаг — наш лучший друг в борьбе с FloodWait.
Для нормальной диагностики сохраняйте: метод, target peer, время запроса, тип сессии, proxy, текст исключения и stack trace. Без этого вы лечите не причину, а шум. Оптимизируем сессии, избегаем лимитов.
Если лог не объясняет сбой, ищите не в Telethon, а в архитектуре сценария: слишком плотный цикл, неверный peer, битая сессия или плохой прокси.
Telethon мастерская
@telethon_workshops_ubt
Ошибки Telethon читаются не по коду, а по месту сбоя: слой, RPC и контекст
Этот пост опубликован в Telegram-канале Telethon мастерская. Подписаться можно по ссылке: @telethon_workshops_ubt.