Rate limit exceeded due to shared buckets

[meooow25]

Describe the bug
A rate limit exceeded error can occur if a certain endpoint shares the rate limit bucket with another endpoint but disgord doesn't know it yet. For example, if I react on a message and immediately unreact, the unreact fails because it shares the bucket with react. Example bot: gist.

I'm hesitant to call this a bug because I understand that this is how Discord works and it is not possible to know the bucket in advance, but it would be nice if the request could be auto-retried if, for instance, it fails due to 429 and its bucket was previously unknown. I will have to manually implement a retry anyway if disgord doesn't do it.

[andersfylling]

I've actually started allowing people to inject anything that implements the http Do interface. So you can use something like heimdall. The only issue right now, is that the rate limit logic then needs to be a http.RoundTripper implementation.

So as soon as a super simple, round tripper algorithm is implemented, this should be fixed if you use something like https://github.com/gojek/heimdall.

[meooow25]

I've actually started allowing people to inject anything that implements the http Do interface.

I see that the client config accepts a http.Client specifically (and not a Do interface), am I missing something?

Thanks for the http.RoundTripper suggestion, using a http.Client with some form of a retrying RoundTripper implementation is an option. I can try to see if it works. If disgord allows Do interfaces I would be able to use a retrying Client instead.

I don't think heimdall is particularly useful here, even if disgord allows Do interfaces, because it does not detect 429s as errors to retry on and I see no way to configure it to do so.

Edit: I just realized that disgord accepts Do interfaces at head

[andersfylling]

The Do support has not been released yet. It only exist in the development branch.