RequestHandler is returning error responses after waiting in _handle_wait_time

[geo-martino]

Musify version

1.0.0

What happened?

KeyErrors appear after running some functions in the SpotifyAPI due to the fact that RequestHandler is returning JSON response data that is an error response with an "error" key present.

What do you think should have happened instead?

After waiting, it should request a new response and return that. It seems that it may be getting a new response and returning it anyway?

Please paste any logs that you see related to this issue here

2024-05-25 11:52:52.337 | [ WARNING] m.a.request.RequestHandler._log_response [ 227] | GET    : https://api.spotify.com/v1/albums/09NmDHOVRAVFjAoz0P6oaY/tracks?offset=0&limit=50 | Code: 429 | Response text and headers follow:
Response text:
{
  "error": {
    "status": 429,
    "message": "API rate limit exceeded"
  }
}
Headers:
{
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Headers": "Accept, App-Platform, Authorization, Content-Type, Origin, Retry-After, Spotify-App-Version, X-Cloud-Trace-Context, client-token, content-access-token",
  "Access-Control-Allow-Methods": "GET, POST, OPTIONS, PUT, DELETE, PATCH",
  "Access-Control-Allow-Credentials": "true",
  "Access-Control-Max-Age": "604800",
  "Retry-After": "17",
  "Access-Control-Expose-Headers": "Retry-After",
  "Content-Encoding": "gzip",
  "strict-transport-security": "max-age=31536000",
  "x-content-type-options": "nosniff",
  "Date": "Sat, 25 May 2024 15:52:53 GMT",
  "Server": "envoy",
  "Via": "HTTP/2 edgeproxy, 1.1 google",
  "Alt-Svc": "h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000",
  "Transfer-Encoding": "chunked"
}
2024-05-25 11:52:52.343 | [    INFO] m.a.r.RequestHandler._handle_wait_time   [ 255] | Rate limit exceeded. Retrying again at 2024-05-25 11:53:09
2024-05-25 11:53:09.350 | [   DEBUG] musify.api.request.RequestHandler.log    [ 218] | GET    : https://api.spotify.com/v1/albums/09NmDHOVRAVFjAoz0P6oaY/tracks        | limit: 50   | offset: 0    |      5/5      tracks | Cached Request
2024-05-25 11:53:09.360 | [CRITICAL] m.processor.musify_cli.processor.main    [ 176] | Traceback (most recent call last):
  File "D:\Projects\musify-cli\musify_cli\__main__.py", line 174, in main
    await processor.run()
  File "D:\Projects\musify-cli\musify_cli\processor.py", line 84, in run
    await super().__call__()
  File "D:\Projects\musify-cli\musify_cli\processor.py", line 491, in new_music
    await self.manager.extend_albums(albums_to_extend)
  File "D:\Projects\musify-cli\musify_cli\manager\_core.py", line 281, in extend_albums
    await self.remote.api.extend_items(album.response, kind=kind, key=key)
  File "D:\Projects\musify\musify\libraries\remote\spotify\api\item.py", line 350, in extend_items
    self._enrich_with_parent_response(
  File "D:\Projects\musify\musify\libraries\remote\spotify\api\item.py", line 270, in _enrich_with_parent_response
    for item in response[self.items_key]:
                ~~~~~~~~^^^^^^^^^^^^^^^^
KeyError: 'items'

How to reproduce

Run enough requests through the API to trigger a rate limit that is within backoff boundaries. Check results

Operating System

Windows 11

Python version

3.12.1

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[geo-martino]

Weirdly, this issue has entirely evaporated. I was seeing it every time a short rate limit of about a minute would happen up until 12 hours ago. However, using the exact same code, this issue is no longer showing for short rate limits. It therefore may have been an issue on Spotify's side.

Marking as resolved for now. Please reopen if it persists.