Open rhiever opened 9 years ago
Implementation concern:
Would it be better to:
1) Keep running until the API rate limit error is thrown, catch that error, sleep until the reset
time, then continue as normal, or
2) Try to be smart about it and keep track of the number of requests left, then sleep when the number of requests left is estimated to be 0.
I'm leaning toward 1)
because it's simpler and doesn't rely on a potentially-complex system for estimating the number of requests left. (e.g., the estimation procedure will be way off if the user is auto_following
via two instances of the bot).
The downside of 1)
is that the user will still regularly run into API rate limit errors -- potentially angering the Twitter API gods -- but at least this new implementation will be smarter about handling the rate limit errors.
It's possible to query the API for how many requests the bot has left: https://dev.twitter.com/rest/reference/get/application/rate_limit_status
self.TWITTER_CONNECTION.application.rate_limit_status()
will return a dictionary that indicates the number of requests left for each type of API request, and how long until that limit is reset.Build this check into each function and either pause until the limit resets or stop (based on user input - sleep by default) once the limit is reached.