[GH-ISSUE #349] bad request when trying to create playlist #107

Closed
opened 2026-02-27 20:23:09 +03:00 by kerem · 7 comments
Owner

Originally created by @fprasx on GitHub (Jul 25, 2022).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/349

Describe the bug
Whenever I try to use user_playlist_create I get Error: http error: status code 400 Bad Request. Other API calls work fine.

To Reproduce
Here is a minimum working example:

use anyhow::Result;
use rspotify::{prelude::*, scopes, AuthCodePkceSpotify, Config, Credentials, OAuth};

#[tokio::main]
async fn main() -> Result<()> {
    env_logger::init();

    let creds = Credentials::from_env().unwrap();

    let oauth = OAuth::from_env(scopes!(
        "playlist-read-collaborative",
        "playlist-read-private",
        "playlist-modify-public",
        "playlist-modify-private"
    ))
    .unwrap();

    let config = Config {
        token_cached: true,
        token_refreshing: true,
        ..Default::default()
    };

    let mut spotify = AuthCodePkceSpotify::with_config(creds, oauth, config);

    // The URL the user enters into the terminal
    let url = spotify.get_authorize_url(None).unwrap();

    match spotify.prompt_for_token(&url).await {
        Ok(_) => (),
        // If the token is too old, refresh it
        // The unwrap still panics sometime and I'm not sure why
        Err(_) => spotify.refresh_token().await.unwrap(),
    }

    let id = &spotify.me().await?.id;
    spotify
        .user_playlist_create(
            id,
            "this is a test",
            Some(true),
            Some(true),
            Some("this is a test"),
        )
        .await?;
    Ok(())
}

This panics with the error "Error: http error: status code 400 Bad Request". The API call spotify.me() works fine.

Expected behavior
I expected the playlist to be created (or have some other error like a network error).

Log/Output data
Running with RUST_LOG=trace cargo run produces the following:

[2022-07-25T13:11:39Z INFO  rspotify::auth_code_pkce] Building auth URL
[2022-07-25T13:11:39Z INFO  rspotify::auth_code_pkce] Generating PKCE codes
[2022-07-25T13:11:39Z INFO  rspotify::clients::oauth] Reading auth token cache
[2022-07-25T13:11:39Z INFO  rspotify::clients::base] Writing token cache
[2022-07-25T13:11:39Z INFO  rspotify_http::reqwest] Making request RequestBuilder { method: GET, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.spotify.com")), port: None, path: "/v1/me/", query: None, fragment: None }, headers: {"authorization": "Bearer [not sure if I can show this]"} }
[2022-07-25T13:11:39Z DEBUG reqwest::connect] starting new connection: https://api.spotify.com/
[2022-07-25T13:11:40Z TRACE mio::poll] registering event source with poller: token=Token(0), interests=READABLE | WRITABLE
[2022-07-25T13:11:40Z TRACE want] signal: Want
[2022-07-25T13:11:40Z TRACE want] signal found waiting giver, notifying
[2022-07-25T13:11:40Z TRACE want] poll_want: taker wants!
[2022-07-25T13:11:40Z TRACE want] signal: Want
[2022-07-25T13:11:40Z TRACE want] signal: Want
[2022-07-25T13:11:40Z DEBUG reqwest::async_impl::client] response '200 OK' for https://api.spotify.com/v1/me/
[2022-07-25T13:11:40Z TRACE want] signal: Want
[2022-07-25T13:11:40Z INFO  rspotify_http::reqwest] Making request RequestBuilder { method: POST, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.spotify.com")), port: None, path: "/v1/users/sergiogonzalo03/playlists", query: None, fragment: None }, headers: {"authorization": "Bearer [not sure if I can show this]", "content-type": "application/json"} }
[2022-07-25T13:11:40Z TRACE want] signal: Want
[2022-07-25T13:11:40Z TRACE want] signal: Want
[2022-07-25T13:11:40Z DEBUG reqwest::async_impl::client] response '400 Bad Request' for https://api.spotify.com/v1/users/sergiogonzalo03/playlists
[2022-07-25T13:11:40Z TRACE want] poll_want: taker wants!
[2022-07-25T13:11:40Z TRACE mio::poll] deregistering event source from poller
[2022-07-25T13:11:40Z TRACE want] signal: Closed

Additional context
N/A

Originally created by @fprasx on GitHub (Jul 25, 2022). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/349 **Describe the bug** Whenever I try to use `user_playlist_create` I get `Error: http error: status code 400 Bad Request`. Other API calls work fine. **To Reproduce** Here is a minimum working example: ```rust use anyhow::Result; use rspotify::{prelude::*, scopes, AuthCodePkceSpotify, Config, Credentials, OAuth}; #[tokio::main] async fn main() -> Result<()> { env_logger::init(); let creds = Credentials::from_env().unwrap(); let oauth = OAuth::from_env(scopes!( "playlist-read-collaborative", "playlist-read-private", "playlist-modify-public", "playlist-modify-private" )) .unwrap(); let config = Config { token_cached: true, token_refreshing: true, ..Default::default() }; let mut spotify = AuthCodePkceSpotify::with_config(creds, oauth, config); // The URL the user enters into the terminal let url = spotify.get_authorize_url(None).unwrap(); match spotify.prompt_for_token(&url).await { Ok(_) => (), // If the token is too old, refresh it // The unwrap still panics sometime and I'm not sure why Err(_) => spotify.refresh_token().await.unwrap(), } let id = &spotify.me().await?.id; spotify .user_playlist_create( id, "this is a test", Some(true), Some(true), Some("this is a test"), ) .await?; Ok(()) } ``` This panics with the error "Error: http error: status code 400 Bad Request". The API call `spotify.me()` works fine. **Expected behavior** I expected the playlist to be created (or have some other error like a network error). **Log/Output data** Running with `RUST_LOG=trace cargo run` produces the following: ``` [2022-07-25T13:11:39Z INFO rspotify::auth_code_pkce] Building auth URL [2022-07-25T13:11:39Z INFO rspotify::auth_code_pkce] Generating PKCE codes [2022-07-25T13:11:39Z INFO rspotify::clients::oauth] Reading auth token cache [2022-07-25T13:11:39Z INFO rspotify::clients::base] Writing token cache [2022-07-25T13:11:39Z INFO rspotify_http::reqwest] Making request RequestBuilder { method: GET, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.spotify.com")), port: None, path: "/v1/me/", query: None, fragment: None }, headers: {"authorization": "Bearer [not sure if I can show this]"} } [2022-07-25T13:11:39Z DEBUG reqwest::connect] starting new connection: https://api.spotify.com/ [2022-07-25T13:11:40Z TRACE mio::poll] registering event source with poller: token=Token(0), interests=READABLE | WRITABLE [2022-07-25T13:11:40Z TRACE want] signal: Want [2022-07-25T13:11:40Z TRACE want] signal found waiting giver, notifying [2022-07-25T13:11:40Z TRACE want] poll_want: taker wants! [2022-07-25T13:11:40Z TRACE want] signal: Want [2022-07-25T13:11:40Z TRACE want] signal: Want [2022-07-25T13:11:40Z DEBUG reqwest::async_impl::client] response '200 OK' for https://api.spotify.com/v1/me/ [2022-07-25T13:11:40Z TRACE want] signal: Want [2022-07-25T13:11:40Z INFO rspotify_http::reqwest] Making request RequestBuilder { method: POST, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.spotify.com")), port: None, path: "/v1/users/sergiogonzalo03/playlists", query: None, fragment: None }, headers: {"authorization": "Bearer [not sure if I can show this]", "content-type": "application/json"} } [2022-07-25T13:11:40Z TRACE want] signal: Want [2022-07-25T13:11:40Z TRACE want] signal: Want [2022-07-25T13:11:40Z DEBUG reqwest::async_impl::client] response '400 Bad Request' for https://api.spotify.com/v1/users/sergiogonzalo03/playlists [2022-07-25T13:11:40Z TRACE want] poll_want: taker wants! [2022-07-25T13:11:40Z TRACE mio::poll] deregistering event source from poller [2022-07-25T13:11:40Z TRACE want] signal: Closed ``` **Additional context** N/A
kerem 2026-02-27 20:23:09 +03:00
Author
Owner

@ramsayleung commented on GitHub (Jul 27, 2022):

Oooh, thanks for your report, I can reproduce this problem, I will dig deep to figure out what's wrong.

PS:
It turns out that there is nothing to do with RSpotify, you can't set public to true and collaborative to true at the same time. According to the Spotify API documentation:

  • public: Defaults to true. If true the playlist will be public, if false it will be private. To be able to create private playlists, the user must have granted the playlist-modify-private
  • collaborative
    Defaults to false. If true the playlist will be collaborative. Note: to create a collaborative playlist you must also set public to false. To create collaborative playlists you must have granted playlist-modify-private and playlist-modify-public
<!-- gh-comment-id:1196184469 --> @ramsayleung commented on GitHub (Jul 27, 2022): Oooh, thanks for your report, I can reproduce this problem, I will dig deep to figure out what's wrong. PS: It turns out that there is nothing to do with `RSpotify`, you can't set `public` to `true` and `collaborative ` to `true` at the same time. According to the Spotify API [documentation](https://developer.spotify.com/documentation/web-api/reference/#/operations/create-playlist): > + public: Defaults to true. If true the playlist will be public, if false it will be private. To be able to create private playlists, the user must have granted the playlist-modify-private > + collaborative Defaults to false. If true the playlist will be collaborative. **Note: to create a collaborative playlist you must also set public to false**. To create collaborative playlists you must have granted playlist-modify-private and playlist-modify-public
Author
Owner

@marioortizmanero commented on GitHub (Jul 27, 2022):

That sounds like a good opportunity to add a debug_assert and improve our errors! #352 should fix it.

<!-- gh-comment-id:1196585399 --> @marioortizmanero commented on GitHub (Jul 27, 2022): That sounds like a good opportunity to add a `debug_assert` and improve our errors! #352 should fix it.
Author
Owner

@fprasx commented on GitHub (Jul 28, 2022):

I saw the fix, thank you! When will the corrected functionality be available to users? I noticed the code is stil the same on docs.rs.

<!-- gh-comment-id:1198226540 --> @fprasx commented on GitHub (Jul 28, 2022): I saw the fix, thank you! When will the corrected functionality be available to users? I noticed the code is stil the same on docs.rs.
Author
Owner

@ramsayleung commented on GitHub (Jul 29, 2022):

When will the corrected functionality be available to users? I noticed the code is stil the same on docs.rs.

What does correct functionality mean? Do you mean the debug_assert statement? The docs.rs will change after we release a new version, so it needs to wait for a while util a new release.

<!-- gh-comment-id:1199166517 --> @ramsayleung commented on GitHub (Jul 29, 2022): > When will the corrected functionality be available to users? I noticed the code is stil the same on docs.rs. What does correct functionality mean? Do you mean the `debug_assert` statement? The docs.rs will change after we release a new version, so it needs to wait for a while util a new release.
Author
Owner

@marioortizmanero commented on GitHub (Jul 29, 2022):

Yup, the next release is blocked by #329. Not sure if we should wait for @SabrinaJewson for that, or if we should fix it ourselves. Once @ramsayleung takes a look at #327 and #337, we can also merge them. #336 would be nice to merge as well, but has less priority and we can leave it for a future version if necessary. Oh, and I might implement #350 if it's simple enough.

<!-- gh-comment-id:1199188146 --> @marioortizmanero commented on GitHub (Jul 29, 2022): Yup, the next release is blocked by #329. Not sure if we should wait for @SabrinaJewson for that, or if we should fix it ourselves. Once @ramsayleung takes a look at #327 and #337, we can also merge them. #336 would be nice to merge as well, but has less priority and we can leave it for a future version if necessary. Oh, and I might implement #350 if it's simple enough.
Author
Owner

@marioortizmanero commented on GitHub (Jul 29, 2022):

Though I wouldn't really call #352 a 'fix'. You should be able to use the current version just fine. The new one will just stop the execution in debug mode if the invariant you were breaking isn't met, but only for usability reasons.

<!-- gh-comment-id:1199220818 --> @marioortizmanero commented on GitHub (Jul 29, 2022): Though I wouldn't really call #352 a 'fix'. You should be able to use the current version just fine. The new one will just stop the execution in debug mode if the invariant you were breaking isn't met, but only for usability reasons.
Author
Owner

@fprasx commented on GitHub (Aug 1, 2022):

Ahh, my mistake with the language. Thank you for the help!

<!-- gh-comment-id:1201466564 --> @fprasx commented on GitHub (Aug 1, 2022): Ahh, my mistake with the language. Thank you for the help!
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/rspotify#107
No description provided.