[GH-ISSUE #309] Rate limit causing HTTP Error 429 #92

New issue

Closed

opened 2026-02-27 20:23:04 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 20:23:04 +03:00

Owner

Originally created by @Marekkon5 on GitHub (Apr 2, 2022).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/309

Describe the bug
You can still hit the rate limit, which causes HTTP status 429.

To Reproduce
Make a loop doing single request such as search. This is kinda hard to reproduce, because it depends on your internet connection, and also luck (Spotify servers might be busy = slower = won't reach the rate limit). In our case it happened randomly after spamming the API for few hours.

Expected behavior
rspotify shouldn't hit it, or retry in case it happens, not return an error.

Log/Output data
http error: status code 429

Additional context
I don't know where the rate limit handling is implemented or how it's implemented.

Originally created by @Marekkon5 on GitHub (Apr 2, 2022). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/309 **Describe the bug** You can still hit the rate limit, which causes HTTP status 429. **To Reproduce** Make a loop doing single request such as search. This is kinda hard to reproduce, because it depends on your internet connection, and also luck (Spotify servers might be busy = slower = won't reach the rate limit). In our case it happened randomly after spamming the API for few hours. **Expected behavior** `rspotify` shouldn't hit it, or retry in case it happens, not return an error. **Log/Output data** `http error: status code 429` **Additional context** I don't know where the rate limit handling is implemented or how it's implemented.

kerem

2026-02-27 20:23:04 +03:00

closed this issue
added the
help wanted

bug
labels

kerem commented

2026-02-27 20:23:05 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Apr 2, 2022):

I honestly don't think rate limiting is something rspotify itself should handle. If your client gets one of these, just wait for the indicated amount of time and retry again.

@marioortizmanero commented on GitHub (Apr 2, 2022): I honestly don't think rate limiting is something rspotify itself should handle. If your client gets one of these, just wait for the indicated amount of time and retry again.

kerem commented

2026-02-27 20:23:05 +03:00

Author

Owner

@Marekkon5 commented on GitHub (Apr 2, 2022):

In that case why isn't there any helper method or error type which would contain the Retry-After amount to make it more user friendly?

@Marekkon5 commented on GitHub (Apr 2, 2022): In that case why isn't there any helper method or error type which would contain the `Retry-After` amount to make it more user friendly?

kerem commented

2026-02-27 20:23:05 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Apr 2, 2022):

The thing is that it was quite hard to wrap all the errors under the same interface. Since we now support both ureq and reqwest, they are reported in different ways depending on what client you're using. It's certainly possible, but for the first version I chose the easiest option and just left the original error types. For now you can check reqwest/ureq's documentation and see how they handle these errors yourself. We could try to wrap the errors in the future, but I remember that it was somewhat complicated when I tried.

@marioortizmanero commented on GitHub (Apr 2, 2022): The thing is that it was quite hard to wrap all the errors under the same interface. Since we now support both ureq and reqwest, they are reported in different ways depending on what client you're using. It's certainly possible, but for the first version I chose the easiest option and just left the original error types. For now you can check reqwest/ureq's documentation and see how they handle these errors yourself. We could try to wrap the errors in the future, but I remember that it was somewhat complicated when I tried.

kerem commented

2026-02-27 20:23:05 +03:00

Author

Owner

@ramsayleung commented on GitHub (Apr 4, 2022):

I honestly don't think rate limiting is something rspotify itself should handle. If your client gets one of these, just wait for the indicated amount of time and retry again.

I agree with Mario's point, rspotify should be a lightweight rust wrapper for the Spotify Web API, instead of an all-in-one clumsy library.

The rate limit error isn't raised from rspotify, rspotify just propagates this error from Spotify Server to client. And rspotify should not cover this up for Spotify Server or handle it for client.

@ramsayleung commented on GitHub (Apr 4, 2022): > I honestly don't think rate limiting is something rspotify itself should handle. If your client gets one of these, just wait for the indicated amount of time and retry again. I agree with Mario's point, rspotify should be a lightweight rust wrapper for the Spotify Web API, instead of an all-in-one clumsy library. The rate limit error isn't raised from `rspotify`, `rspotify` just propagates this error from Spotify Server to client. And `rspotify` should not cover this up for Spotify Server or handle it for client.