Как читать ошибки Telethon и не гадать по RPC-рунам

Как читать ошибки Telethon и не гадать по RPC-рунам

Telethon почти всегда говорит достаточно, если смотреть не на текст исключения, а на связку: класс ошибки, код RPC и контекст запроса. Начинайте с errors в логах: там видно, на каком методе упал вызов, какой peer был выбран и был ли вообще ответ от сервера.

Главные группы:
— FloodWaitError: лимит не на «скрипт», а на действие. Нужен backoff, а не повтор в лоб.
— PhoneCodeInvalidError / SessionPasswordNeededError: проблема не в сети, а в auth-flow.
— PeerFloodError: Telegram режет массовые действия, даже если RPC формально успешен.
— ChannelPrivateError / UserIdInvalidError: проверяйте доступ к сущности и актуальность entity cache.

Смотрите на стек вызовов сверху вниз. Если ошибка возникает на этапе resolve username, проблема в резолве entity; если на invoke, уже ломается сам метод. Для этого полезно логировать: метод, аргументы, результат resolve, id сущности, тип сессии и прокси. Без этого любой анализ превращается в угадайку.

Важный сигнал — повторяемость. Один RPCError может быть случайностью, серия одинаковых ошибок обычно означает системную причину: сломанную сессию, устаревший кеш, неверный proxy, слишком агрессивный rate. Дебаг — наш лучший друг в борьбе с FloodWait.

Если лог пустой, проблема часто не в Telethon, а в уровне logging и перехвате исключений. Оптимизируем сессии, избегаем лимитов.