Ошибка Telethon — это не баг, а ответ сервера: учимся читать RPC
Telethon редко ломается «молча». Почти всегда в ответе есть тип ошибки, код и контекст: FloodWait, RPCError, AuthKeyUnregistered, SessionPasswordNeeded. Если не смотреть в текст исключения, скрипт превращается в угадайку. Разбираем логи ошибок: что пошло не так на стороне API?
Смотри не только на класс исключения, но и на параметры. FloodWaitError важен не сам по себе, а числом секунд в e.seconds. PhoneNumberBanned, PeerFlood, ChatWriteForbidden указывают на разные ограничения: аккаунт, лимит поведения или права в чате. Один и тот же retry-лoop для них вреден.
В логах Telegram полезны три слоя: что отправили, какой объект вернулся, где именно упали. Если запрос был к каналу, проверь, есть ли доступ у сессии; если к инвайту — не упираешься ли в лимиты; если к отправке сообщения — не схлопнулся ли peer в недоступный диалог. Оптимизируем сессии, избегаем лимитов.
Практика простая: логируй method, peer, текст ошибки и время ожидания, а обработку делай по типу исключения, не по строке. Дебаг — наш лучший друг в борьбе с FloodWait.
Telethon мастерская
@telethon_workshops_ubt
Ошибка Telethon — это не баг, а ответ сервера: учимся читать RPC
Этот пост опубликован в Telegram-канале Telethon мастерская. Подписаться можно по ссылке: @telethon_workshops_ubt.