[GH-ISSUE #1149] Invalidate cache if the credentials change (or the credentials become invalid) #676

Open
opened 2026-02-28 00:00:46 +03:00 by kerem · 4 comments
Owner

Originally created by @vitorbaptista on GitHub (Jul 25, 2024).
Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/1149

Originally assigned to: @dieser-niko on GitHub.

Is your feature request related to a problem? Please describe.

Spotify blocked one of my API keys. I noticed this when I was running a simple Spotipy example (just searching an artist name), and Spotipy failed after retrying 3 times. I changed the credentials on my Spotipy script, but the failure was the same. After ~2 hours of debugging, I realized that Spotipy was using the .cache with the old key so, after deleting this file, it used my new key and everything worked.

Describe the solution you'd like

I see two potential solutions:

  1. Include a hash of the credentials in the cache. If this hash changes, invalidate the cache. This feels correct.
  2. Invalidate the cache if the credentials become invalid. This is already done for timeouts, but AFAIK it isn't done in the case where the API key is blocked by Spotify.

Describe alternatives you've considered

It wasn't clear that the issue was with my credentials. I just ran Spotipy and it took a while to run (because it was retrying 3x), and then failed with a 429 Too Many Requests error. A clearer error message would have made my life easier.

Originally created by @vitorbaptista on GitHub (Jul 25, 2024). Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/1149 Originally assigned to: @dieser-niko on GitHub. **Is your feature request related to a problem? Please describe.** Spotify blocked one of my API keys. I noticed this when I was running a simple Spotipy example (just searching an artist name), and Spotipy failed after retrying 3 times. I changed the credentials on my Spotipy script, but the failure was the same. After ~2 hours of debugging, I realized that Spotipy was using the `.cache` with the old key so, after deleting this file, it used my new key and everything worked. **Describe the solution you'd like** I see two potential solutions: 1. Include a hash of the credentials in the cache. If this hash changes, invalidate the cache. This feels correct. 2. Invalidate the cache if the credentials become invalid. This is already done for timeouts, but AFAIK it isn't done in the case where the API key is blocked by Spotify. **Describe alternatives you've considered** It wasn't clear that the issue was with my credentials. I just ran Spotipy and it took a while to run (because it was retrying 3x), and then failed with a 429 Too Many Requests error. A clearer error message would have made my life easier.
Author
Owner

@dieser-niko commented on GitHub (Jul 26, 2024):

Your first potential solution would be effective and quite simple to implement. While reading up to this point, I was thinking of something similar.

I'll start working on a new CacheHandler, this shouldn't be too hard.

<!-- gh-comment-id:2252148024 --> @dieser-niko commented on GitHub (Jul 26, 2024): Your first potential solution would be effective and quite simple to implement. While reading up to this point, I was thinking of something similar. I'll start working on a new CacheHandler, this shouldn't be *too* hard.
Author
Owner

@dieser-niko commented on GitHub (Jul 26, 2024):

So currently there's something similar, but for usernames. Basically the username is appended to the end of the filename.

I'll probably go down a similar route, but reduce the hash length to 7 chars.

I also thought about hijacking the username parameter as it's marked as deprecated, but that just feels wrong if this is supposed to be official :)

<!-- gh-comment-id:2252712806 --> @dieser-niko commented on GitHub (Jul 26, 2024): So currently there's something similar, but for usernames. Basically the username is appended to the end of the filename. I'll probably go down a similar route, but reduce the hash length to 7 chars. I also thought about hijacking the username parameter as it's marked as deprecated, but that just feels wrong if this is supposed to be official :)
Author
Owner

@dieser-niko commented on GitHub (Jul 30, 2024):

After some internal discussions with @stephanebruckert, we came to the conclusion that this change should be kept for the v3 release, as it would be somewhat difficult and unstable to implement a solution that is also backwards compatible. Also, this problem does not only affect the CacheFileHandler, but pretty much any other cache handler that has some kind of name attribute.

<!-- gh-comment-id:2258057791 --> @dieser-niko commented on GitHub (Jul 30, 2024): After some internal discussions with @stephanebruckert, we came to the conclusion that this change should be kept for the v3 release, as it would be somewhat difficult and unstable to implement a solution that is also backwards compatible. Also, this problem does not only affect the `CacheFileHandler`, but pretty much any other cache handler that has some kind of name attribute.
Author
Owner

@vitinhohhh commented on GitHub (Mar 9, 2025):

https://github.com/spotipy-dev/spotipy/issues/1149#issue-2430410583

<!-- gh-comment-id:2708607585 --> @vitinhohhh commented on GitHub (Mar 9, 2025): https://github.com/spotipy-dev/spotipy/issues/1149#issue-2430410583
Sign in to join this conversation.
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
starred/spotipy#676
No description provided.