You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes it's better for a rate limited request to fail with an error and let the library user decide what to do.
For example, I update a channel's topic periodically with info from an external data source. The rate limiting on channel edits is quite severe, two requests in 10 minutes, and hitting that limit causes DiscordGo to sleep for several minutes before retrying my now stale request. It would be better if I could send a new request with updated data instead.
Ideally retry would be disabled on a per-request basis, but I can't see a way to implement that without major API changes. Instead a field like ShouldRetryOnRateLimit could be added to Session, defaulting to true. Unfortunately this would force the user to decide the rate limiting policy globally for their application, and it couldn't be changed in a thread-safe manner. Finally, the automatic retry logic could be removed entirely and left to the user. Obviously this would be a breaking change. Other solutions would be appreciated.
The text was updated successfully, but these errors were encountered:
Sometimes it's better for a rate limited request to fail with an error and let the library user decide what to do.
For example, I update a channel's topic periodically with info from an external data source. The rate limiting on channel edits is quite severe, two requests in 10 minutes, and hitting that limit causes DiscordGo to sleep for several minutes before retrying my now stale request. It would be better if I could send a new request with updated data instead.
Ideally retry would be disabled on a per-request basis, but I can't see a way to implement that without major API changes. Instead a field like
ShouldRetryOnRateLimit
could be added to Session, defaulting to true. Unfortunately this would force the user to decide the rate limiting policy globally for their application, and it couldn't be changed in a thread-safe manner. Finally, the automatic retry logic could be removed entirely and left to the user. Obviously this would be a breaking change. Other solutions would be appreciated.The text was updated successfully, but these errors were encountered: