Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rate limiting #20

Open
watzon opened this issue Apr 14, 2020 · 7 comments
Open

Rate limiting #20

watzon opened this issue Apr 14, 2020 · 7 comments

Comments

@watzon
Copy link
Collaborator

watzon commented Apr 14, 2020

Telegram has two separate rate limit conditions in place. The first is that a bot cannot send more than 30 (or so) messages per second. The second is that a bot cannot send more than 20 messages to the same group per minute. If either of these limits are hit the bot will start getting 429 errors.

It would be nice, though not absolutely imperative, to have a rate limiter in place to keep the bot from hitting these limits. The challenge is not so much the first condition, but the second.

@Poolitzer
Copy link

@watzon Issue with that is that some people rather deal with the flood limits themselves then only having a "the method is maybe sending the reply in time".

So that needs to be an opt-in/out functionality imo.
Ptb offers a message queue for example.

@watzon
Copy link
Collaborator Author

watzon commented Apr 14, 2020

Yeah that's the main reason I haven't added it yet. I need to think of not only the best way to do so, but how to do it in such a way that it's opt-in. A message queue isn't the worst idea.

@Poolitzer
Copy link

@watzon Well the queue is just a different module. I think in python its being done with decorators, not sure your cristal has those.

There are a lot of different ways to implement rate limit dealing. Telethon for example silently expects them, checks if the wait time is under X seconds, if yes, waits those seconds out and send it then, if not, raises the error and lets the user deal with it. Also a possibility

@watzon
Copy link
Collaborator Author

watzon commented Apr 14, 2020

@Poolitzer Yeah, Crystal has annotations. Not sure if that's the way I'd go with this or not. I'll have to do some brainstorming. Just retrying after a failure may be the easiest way to go about things, I guess we'll see.

@Poolitzer
Copy link

@watzon It definitely is the easiest, but as I said easier, some people might not like that cause it breaks their flow

@gabbhack
Copy link

Keep in mind that Telegram increases the limits of the popular bots

@watzon
Copy link
Collaborator Author

watzon commented May 28, 2020

True. Ideally any limiter should be both optional and configurable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants