Что делать если юзер-бот получает очень много сообщений?

Question

[aygumov]

Есть обычный юзер бот (на библиотеке pyrogram) который выполняет какую-то специально заданную ему задачу, а именно в качестве примера обычную обработку сообщений:

@app.on_message()
async def messages(client, message):
    print(message.text)

Всё бы вроде хорошо, и код реально выводит все полученные сообщения. Но, проблема начинается с того момента как юзер-бот начинает получать очень много сообщений и следовательно начинает спамить в консоль socket.send() raised exception. или [10] Retrying "updates.GetChannelDifference" due to: Request timed out.

В принципе понятно что проблема возникает в самой библиотеки pyrogram в методе GetChannelDifference(), ведь на сколько я знаю он не может обрабатывать больше 100 сообщений в минуту для аккаунта пользователя.

Как можно решить эту проблему? Может быть нужно установить специальный счётчик который будет перезапускать сам клиент если в минуту было отправлено больше положенного сообщений. Но и тут возникает проблема, ведь после перезапуска клиента app.restart() бот просто перестаёт реагировать на какие-либо события.

Comments

[776166]

Что-то это странно выглядит и не так, как вы описываете.
socket.send() raised exception — это попытка что-то куда-то послать по сети. Но никак не в консоль.

[10] Retrying "updates.GetChannelDifference" due to: Request timed out

— Это попытка что-то получить, которая отваливается по таймауту.

Я бы сказал, что это больше похоже на проблемы с сетью, которая нестабильная какая-то и теряет данные.

С чего бы программа не могла обрабатывать больше 2 сообщений в секунду? Это же фигня, а не нагрузка.. Если такое ограничение есть, то почему оно вообще существует в библиотеке? Может, сменить библиотеку?

[rPman]

нет там все очевидно, на каждое собщение об обновлении в канале код библиотеки запрашивает это новое сообщение достаточно тяжелой командой MessageRange указывая начальное и конечное сообщение одно и то же, при превышении лимита запросов сервер просто не обрабатывает его

это идеологический баг в библиотеке

Answer 1

[rPman]

разум подсказывает что можно модифицировать код client.py таким образом, чтобы не каждый update генерировал вызов GetChannelDifference, пропускать если с предыдущего раза прошло не меньше X миллисекунд (например секунда) то запускать/обновлять асинхронный таймер запуска этого update принудительно, чтобы обновление все же было вызвано

так же GetChannelDifference вызывает метод MessageRange(min_id=update.message.id,max_id=update.message.id) очивидно сделано неправильно, этот метод грузит только ОДНО сообщение, а нужно сохранять id старого сообщения и делать min_id равным им.

в результате обновления будут запаздывать на секунду, если они слишком частые, но вызываться будут не чаще

p.s. в этом сила опенсорс, есть ошибка, ее можно найти, понять исправить и по возможности отправить патч в менйстрим