Ошибка Telethon — это не баг, а ответ сервера: учимся читать RPC

Ошибка Telethon — это не баг, а ответ сервера: учимся читать RPC

Telethon редко ломается «молча». Почти всегда в ответе есть тип ошибки, код и контекст: FloodWait, RPCError, AuthKeyUnregistered, SessionPasswordNeeded. Если не смотреть в текст исключения, скрипт превращается в угадайку. Разбираем логи ошибок: что пошло не так на стороне API?

Смотри не только на класс исключения, но и на параметры. FloodWaitError важен не сам по себе, а числом секунд в e.seconds. PhoneNumberBanned, PeerFlood, ChatWriteForbidden указывают на разные ограничения: аккаунт, лимит поведения или права в чате. Один и тот же retry-лoop для них вреден.

В логах Telegram полезны три слоя: что отправили, какой объект вернулся, где именно упали. Если запрос был к каналу, проверь, есть ли доступ у сессии; если к инвайту — не упираешься ли в лимиты; если к отправке сообщения — не схлопнулся ли peer в недоступный диалог. Оптимизируем сессии, избегаем лимитов.

Практика простая: логируй method, peer, текст ошибки и время ожидания, а обработку делай по типу исключения, не по строке. Дебаг — наш лучший друг в борьбе с FloodWait.