-
Notifications
You must be signed in to change notification settings - Fork 954
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
POST playlist_add_items not retrying (HTTPError: 429 API rate limit exceeded) #577
Comments
Hey @stephanebruckert I wasn't able to replicate this issue in my environment (spotipy==2.15.0, ubuntu 20.04.1 LTS, xterm) - though that might be because our networks are different. I think the root issue is that spotipy can't currently handle API rate limit exceeding as we're raising exceptions on any HTTPError. A solution might exist in the parsing of |
Try this: (by the way, to test it against the main branch on your local clone, the script just needs to be placed at the root of the project) from concurrent.futures import ThreadPoolExecutor
import spotipy
TOTAL_ITEMS_TO_ADD = 400
MAX_WORKERS = 50
PLAYLIST_OWNER_ID = "your_user_id"
# Spotify init
sp = spotipy.Spotify(auth_manager=spotipy.SpotifyOAuth(scope='playlist-modify-public playlist-modify-private',
show_dialog=True))
some_track_id = sp.search('test')['tracks']['items'][0]['uri']
playlist = sp.user_playlist_create(PLAYLIST_OWNER_ID, "test", False)
ids_to_add = [some_track_id] * TOTAL_ITEMS_TO_ADD
def add_item(track_id):
# It does not work with POST:
sp.playlist_add_items(playlist['id'], [track_id], 0)
# It works with GET
# sp.search('test')
print("Success")
with ThreadPoolExecutor(max_workers=MAX_WORKERS) as pool:
pool.map(add_item, ids_to_add)
I think here Also it works well for GET as it correctly retries:
I wonder, why does it work for GET and not for POST, knowing that both our GET and POST methods call the same PS: I just found this https://stackoverflow.com/a/35707701/1515819, that might be our solution! |
@Quizz1Cal @ritiek please review this fix if you get a chance #596 |
@stephanebruckert I think its worth noting that there is a reason that urllib does not do retries for POSTS and that is because they are not considered safe or idempotent. GET, PUT, and DELETE fall into these categories but POST however does not. More detail can be found in RFC7231. Having retries on POSTs can have unintended consequences like having multiple records created in the database if there was an error upon creation. It is my personal opinion that this should not have been created as it is not an issue for the following reasons:
Please let me know if I am missing something and I am open to hearing out the reasons for the change, but I figured I would add my 2 cents as I helped contribute the change to the retry logic. |
Sorry for the late response I was bit busy recently. Thanks also for the inputs that's all fair points. It's my bad, I should have waited for feedback on the PR, but I'm happy to discuss it here now and am also happy to revert things if needed Answering your points in order:
Great to discuss this!! |
Related to the first point about always retrying on 429, I just found we could use
I'm going to open a PR to set Edit: did a quick test and doesn't seem to work |
@stephanebruckert no worries! Everyone gets busy and I am late to responding as well. I am glad we are talking about this as I always find this topic interesting! It seems like your main reason was to have to respect the After looking into it:
Also just to clear some things up in the comment with bullet points:
So where does this leave us?
Again really enjoying talking about this :) good stuff to think about and a fun topic! |
I'm having the same issue and decided to downgrade to spotipy==2.4.4 where I know it works for sure. retrying ...1secs |
I'm getting the same issue occasionally in my scripts. I'm wondering if it's an issue at Spotify's end? |
All methods should be retrying but
playlist_add_items
doesn't seem to:Tried with 2.15.0 and 2.10.0
The text was updated successfully, but these errors were encountered: