-
Notifications
You must be signed in to change notification settings - Fork 959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry does not wait, retries immediately, which increase rate limit. #1158
Comments
The linked code is currently not released, so this shouldn't be the reason for the increase in the retry after value. But it should help to recognize when rate limits are being reached by warning the user. |
It would be helpful if you could provide a minimal, reproducible example. Some functions have different rate/request limits (and probably also bantime) so it would be good to know how much and what functions your script called. |
This comment was marked as resolved.
This comment was marked as resolved.
I've looked deeper into this and it looks like there is no issue. urllib3 library respects the retry-after header (via respect_retry_after_header=True as the default). However there are a few things worth noting as a result of the issue
I'm happy for the issue to be closed. Maybe the proposed examples could make it clearer how to surface info about rate limiting to library users and how to manage rate limiting in a custom way. I don't have any easy way to demo my problem since it arose from creating playlists with tens of thousands of songs (including search for each song). This is my script to manually display the time in the retry-after header (after having already been rate limited):
|
Looks like you probably hit (what we call) a request limit, not a rate limit. Then there's the request limit. Basically the same as the first, but with a much larger window. It may only be triggered after about 4000 requests (depending on the function). The Retry-After value is also scaled up, in some cases it can be more than a day before another request can be made. This one is not documented though, so we can only speculate. As for your suggestion of throwing some sort of error, I'd say that's too much, as this could be unexpected behaviour. As for the warning message, I've already mentioned that the code in util.py hasn't been released yet and would work without having to set up logging. If a user really wants an error to be raised, they can just say |
One last note, I had a discussion with chaffinched about rate/request limits, you can find it here if you're interested: #913 (comment) |
I was rate limited by spotify and did not respond to it, continuing to request. This increases the amount of time in the
Retry-After
header before the limit is removed. By the time I realized it and responded to it my Retry-After time had become about 2h before I could use the api again.Does it require a
time.sleep(int(retry_header))
at L169?spotipy/spotipy/util.py
Lines 164 to 175 in d9da5af
It seems to me the retry is done immediately instead of being paused for the time requested by the spotify header value.
More context about rate limiting: https://developer.spotify.com/documentation/web-api/concepts/rate-limits#develop-a-backoff-retry-strategy
The text was updated successfully, but these errors were encountered: