-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
Comments
@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. |
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. |
@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 |
@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. |
@watzon It definitely is the easiest, but as I said easier, some people might not like that cause it breaks their flow |
Keep in mind that Telegram increases the limits of the popular bots |
True. Ideally any limiter should be both optional and configurable. |
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.
The text was updated successfully, but these errors were encountered: