In the event of failure (e.g. getting rate limited by the server, HTTP exceptions, any
other exceptions), will retry indefinitely until successful.
This is not strictly the correct thing to do in all scenarios. But it's a lot more
difficult to try to differentiate what failures should and not should not retry, so leave
it up to the user to press Ctrl-C to manually cancel if they do not want to retry.
It might be best to only wrap calls that are made repeatedly. If all the setup is done
earlier, when instantiating the discord.Client, that could catch a substantial class of
failures for which retry might not be applicable.
Note that I have been unable to recreate a 429 (Rate Limited) in practice, but the code supports it.
when wrapped with the
@discord_retrydecoratorIn the event of failure (e.g. getting rate limited by the server, HTTP exceptions, any other exceptions), will retry indefinitely until successful.
This is not strictly the correct thing to do in all scenarios. But it's a lot more difficult to try to differentiate what failures should and not should not retry, so leave it up to the user to press Ctrl-C to manually cancel if they do not want to retry.
It might be best to only wrap calls that are made repeatedly. If all the setup is done earlier, when instantiating the discord.Client, that could catch a substantial class of failures for which retry might not be applicable.
Note that I have been unable to recreate a 429 (Rate Limited) in practice, but the code supports it.
For simplicity, I am using the decorator package, which adds one more requirement to the virtualenv. https://pypi.org/project/decorator/ https://github.com/micheles/decorator/blob/master/docs/documentation.md