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

Ошибки 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, битая сессия или плохой прокси.