feat: ratelimit prediction #2188
Conversation
Signed-off-by: VincentRPS <[email protected]>
…ts to bucketstorage also adds the ability to modify bucket storage for distribution or shared data, using something like Redis.
|
Please add a changelog entry |
|
Changelog requirements met |
Co-authored-by: JustaSqu1d <[email protected]> Signed-off-by: VincentRPS <[email protected]>
pain. it was all pain.
Forgot to add bucket storage to slots. Signed-off-by: VincentRPS <[email protected]>
|
Please add a changelog entry |
|
Changelog requirements met |
Co-authored-by: Emre Terzioglu <[email protected]> Signed-off-by: VincentRPS <[email protected]>
Signed-off-by: VincentRPS <[email protected]>
Signed-off-by: VincentRPS <[email protected]>
It's not hard to make the code yourself so I won't provide it but I did two different tests. Creating / Deleting Channels inside a guild: You can also do your own tests, anything that surpasses the limit of any endpoint is fine. Do, however, avoid testing interactions or anything webhook-related since due to the complexity at the moment of implementing that. I may do that in the future in a separate PR since it does seem feasible. Mostly, to properly implement rate limit prediction into that, I would need to make an entirely different Webhook class for only interaction followups. A massive pain, and probably isn't worth doing for now. |
Co-authored-by: Emre Terzioglu <[email protected]> Signed-off-by: VincentRPS <[email protected]>
Summary: if two or more requests get rate limited at the same time with the same bucket, they will override each other. To fix this without using any locks, we just set the temp bucket before any rate limit can happen, and set it to rate limited once there is one, therefore the only thing being overridden in the `rate_limited` variable to True.
|
PR is mostly finalized by this point. The final goal now is to try and test this system on larger bots to identify any possible faults before it is merged into master. This PR will not be refactoring webhooks, at least for now. That will be the goal of a second PR in 2.6 or 2.7, as the work for that would be a bit more complicated, especially with interaction followups. There is a chance we could make interactions use the HTTPClient instead of Webhooks though which would be much easier to handle since it would just integrate with the current rate limit prediction system. |
Signed-off-by: Dorukyum <[email protected]>
rate_limited is now set to False by default. There is a lock on .use to prevent multiple requests from all releasing requests at the same time. Signed-off-by: VincentRPS <[email protected]>
Summary
This replaces the previous system of rate limit, which purely only handled rate limits, with
a new rate limit system which not only eases and handles rate limits but also tries to predict rate limits before they can happen and affect the bot. This system is made to be scalable and replaceable with something like Redis storage.
Information
examples, ...).
Checklist
type: ignorecomments were used, a comment is also left explaining why.