feature idea - track internal ratelimiting #470

New issue

Open

opened 2017-11-07 09:13:06 -08:00 by jvanasco · 2 comments

jvanasco commented

2017-11-07 09:13:06 -08:00

(Migrated from github.com)

Has anyone considered tracking ratelimits within Twython, to avoid hitting their API when it will most-likely fail? We have a lot of code that does it externally. I want to avoid network trips that won't work.

👍 1

michaelhelmick commented

2017-11-08 10:33:04 -08:00

(Migrated from github.com)

You can use get_application_rate_limit_status to get your applications current rate limit status. You can also except on TwythonRateLimitError or access the rate limiting header (c9026247ee/docs/usage/advanced_usage.rst (access-headers-of-previous-call))

You can use `get_application_rate_limit_status` to get your applications current rate limit status. You can also `except` on `TwythonRateLimitError` or access the rate limiting header (https://github.com/ryanmcgrath/twython/blob/c9026247ee03bc8b22750a87ecf6425094ca77ee/docs/usage/advanced_usage.rst#access-headers-of-previous-call)

jvanasco commented

2017-11-08 10:53:31 -08:00

(Migrated from github.com)

Let me clarify: we use all those techniques right now to populate a dict associated with the connection, that tracks the ratelimiting for each endpoint.

so a request for a timeline will set in our tracking dict the limit/remaining/reset timers for that endpoint (available via the last headers). before making a call, I check that dict to ensure it's likely to succeed and/or reset the timer. If the request is likely to fail, I raise a ratelimit error. this avoids hitting the server for very-likely failure situations. this also lets us check to see if we have any requests left before hitting the API, so we can cycle in another token if handy.

this is all done outside of twython though... and would likely be better written and maintained if the community at-large were interested in it.

Let me clarify: we use all those techniques right now to populate a dict associated with the connection, that tracks the ratelimiting for each endpoint. so a request for a timeline will set in our tracking dict the limit/remaining/reset timers for that endpoint (available via the last headers). before making a call, I check that dict to ensure it's likely to succeed and/or reset the timer. If the request is likely to fail, I raise a ratelimit error. this avoids hitting the server for very-likely failure situations. this also lets us check to see if we have any requests left before hitting the API, so we can cycle in another token if handy. this is all done outside of twython though... and would likely be better written and maintained if the community at-large were interested in it.

No labels

Bug

Enhancement

Feature Suggestion

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: code/twython#470

No description provided.

Rows
Columns