-
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
GET /me/player + 429 Rate Limit exceeded = blocking calls #766
Comments
Besides setting retries=0, another fix is to add I'm all for services provide feedback about rate limits but these should also be communicated to the end user. So I would find it a better solution not to retry on 429 error codes and instead fail. Rate limits only get worse with constant retrying .... |
The entire requests library uses blocking APIs. The thread is blocked during network requests as well; requests does not support async. The retry delay is just generally longer than the delay between making a network request and receiving a response, so it's more noticable.
Presumably, the |
True that since the However urllib3 does offer the possibility of deactivating the Guess what I found confusing was that my call to On the other hand, I didn't know I was hitting rate limits since spotipy was retrying for me. My workaround now is to have |
The import spotipy, requests, urllib3
session = requests.Session()
retry = urllib3.Retry(
total=0,
connect=None,
read=0,
allowed_methods=frozenset(['GET', 'POST', 'PUT', 'DELETE']),
status=0,
backoff_factor=0.3,
status_forcelist=(429, 500, 502, 503, 504),
respect_retry_after_header=False # <---
)
adapter = requests.adapters.HTTPAdapter(max_retries=retry)
session.mount('http://', adapter)
session.mount('https://', adapter)
spotify = spotipy.Spotify(
auth_manager=spotipy.SpotifyPKCE(
scope="",
state=None,
cache_handler=spotipy.CacheFileHandler()
),
requests_session=session
) |
Of course! I noticed the I would go back to 3 retries but simply ignore the retry_after header. Cheers and thanks for the heads-up! |
Hi, I have been running into a similar (if not the same) issue. When I try to get spotify data about an artist by using their artist() function, it gets stuck in the sleep_for_retry() function and it does not tell me how to to sleep for. Here is my code for getting data for an artist: for more details about my original problem, I previously created a issue that was closed here: issue #956 I just tried the solution from @Peter-Schorn here in this issue and I can't figure out how to get it working or if that would even solve my sleep_for_retry() problem. I created a session like this, *note my spotipy.Spotify() function wouldn't work unless I added my client_id and redirect_uri within the auth_manager:
After that I try making a request to get data about an artist like so: But I get this error that seems like there is a problem getting my access token:
I tried passing my access token in the original auth_manager as different parameters such as 'client_secret' or 'code' as it shows in the error message but had no luck. Does anyone have an advice or tips for me? |
The Access token, client id, and authorization code are all different things.
Try providing a non-empty authorize scope string. |
Describe the bug
Currently my API limit is used up so I'm constantly getting API rate limit exceeded (error code 429) from the Spotify API. Which means that spotipy is doing a lot of request retrying. However this causes calls to block and hang because Spotify is setting
the
retry_after
header to 3600. The retry_after header is respected by the urllib3 (I assume) and it's waiting for an hour to retry the call.I've set the request_timeout option to 5 (i.e. 5 seconds) and retries to 3 but the very first retry will block. So the only fix at the moment is to set retries to zero. Then the call will fail immediately.
Your code
spoitpy.Spotify().current_playback() # <--- this hangs/blocks for an hour....
Expected behavior
I would expect that request_timeout would be respected and the call would timeout after request_timeout seconds. Then a second retry would be made that would also fail after request_timeout ... etc.
Output
No ouptut, call hangs/blocks.
Environment:
My point is that this was unexpected behaviour and I initially assumed that Spotify was having an issue. The only thing I was seeing was that my calls to current_playback were hanging and blocking my code. Then I came to discover that spotipy does automagical retries. And then I realised there was a retry_after header ...
So the end result was that Spotify killed my application my setting a header that spotipy blindly respects even though that an hour is far more that than the request_timeout value set in spotipy. I guess it would be nice if the default settings of spotipy would be more obvious when a API rate limit is hit - I only found out that I had a rate limit issue by doing a corresponding curl request.
The text was updated successfully, but these errors were encountered: