starred/rspotify

Fork 0

mirror of https://github.com/ramsayleung/rspotify.git synced 2026-04-26 16:05:53 +03:00

[GH-ISSUE #63] Get Player Error Reasons #21

New issue

Closed

opened 2026-02-27 20:22:38 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 20:22:38 +03:00

Owner

Originally created by @sputnick1124 on GitHub (Nov 9, 2019).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/63

Over in spotify-tui, I am getting API errors fairly frequently. Much of the time, the error code is 403 (I am able to see that now since https://github.com/ramsayleung/rspotify/pull/62), which likely means that I am getting a player error, but I get no more information than that.

I'm not great at web stuff; I don't understand what is happening to this object in the request response. I figured I would be able to define a struct to hold the player error:

struct PlayerError {
    status: u16,
    message: String, 
    reason: String,
}

and then (deserialize the json)[https://docs.rs/reqwest/0.10.0-alpha.1/reqwest/struct.Response.html#method.json] from the response directly into it, but reqwest seems to be hiding the json from me somehow. What's happening to it? How can I get access to the error reason? This would help immensely in providing more information about failure to both developers and end-users.

I'm happy to implement any changes that need to happen, but I don't have much experience handling web requests, and none of that experience is with Rust/reqwest, so any other devs here that could shed some light would be appreciated.

Originally created by @sputnick1124 on GitHub (Nov 9, 2019). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/63 Over in [`spotify-tui`](https://github.com/Rigellute/spotify-tui), I am getting API errors fairly frequently. Much of the time, the error code is 403 (I am able to see that now since https://github.com/ramsayleung/rspotify/pull/62), which likely means that I am getting a [player error](https://developer.spotify.com/documentation/web-api/reference/object-model/#player-error-object), but I get no more information than that. I'm not great at web stuff; I don't understand what is happening to this object in the request response. I figured I would be able to define a struct to hold the player error: ```rust struct PlayerError { status: u16, message: String, reason: String, } ``` and then (deserialize the json)[https://docs.rs/reqwest/0.10.0-alpha.1/reqwest/struct.Response.html#method.json] from the response directly into it, but `reqwest` seems to be hiding the json from me somehow. What's happening to it? How can I get access to the error reason? This would help immensely in providing more information about failure to both developers and end-users. I'm happy to implement any changes that need to happen, but I don't have much experience handling web requests, and none of that experience is with Rust/`reqwest`, so any other devs here that could shed some light would be appreciated.

kerem closed this issue

2026-02-27 20:22:38 +03:00

kerem commented

2026-02-27 20:22:39 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Nov 9, 2019):

For reference, this is what I see when interacting with the endpoint through the (API

{
  "error": {
    "status": 404,
    "message": "Player command failed: No active device found",
    "reason": "NO_ACTIVE_DEVICE"
  }
}

The Response object from reqwest, however, does not seem to provide any access to that json object. It would seem I am potentially missing something obvious, but I don't know what.

Response { 
    url: "https://api.spotify.com/v1/me/player/play?device_id=4a205e1455078ac27724255dd891265738f17dfe", 
    status: 404, 
    headers: {
        "content-type": "application/json; charset=utf-8",
        "cache-control": "private, max-age=0",
        "access-control-allow-origin": "*",
        "access-control-allow-headers":"Accept, App-Platform, Authorization, Content-Type, Origin, Retry-After, Spotify-App-Version",
        "access-control-allow-methods": "GET, POST, OPTIONS, PUT, DELETE, PATCH",
        "access-control-allow-credentials": "true",
        "access-control-max-age": "604800",
        "transfer-encoding": "chunked",
        "date": "Sat, 09 Nov 2019 13:41:32 GMT",
        "via": "1.1 google",
        "alt-svc": "clear"
    }
}

@sputnick1124 commented on GitHub (Nov 9, 2019): For reference, this is what I see when interacting with the endpoint through the (API ```json { "error": { "status": 404, "message": "Player command failed: No active device found", "reason": "NO_ACTIVE_DEVICE" } } ``` The `Response` object from `reqwest`, however, does not seem to provide any access to that json object. It would seem I am potentially missing something obvious, but I don't know what. ``` Response { url: "https://api.spotify.com/v1/me/player/play?device_id=4a205e1455078ac27724255dd891265738f17dfe", status: 404, headers: { "content-type": "application/json; charset=utf-8", "cache-control": "private, max-age=0", "access-control-allow-origin": "*", "access-control-allow-headers":"Accept, App-Platform, Authorization, Content-Type, Origin, Retry-After, Spotify-App-Version", "access-control-allow-methods": "GET, POST, OPTIONS, PUT, DELETE, PATCH", "access-control-allow-credentials": "true", "access-control-max-age": "604800", "transfer-encoding": "chunked", "date": "Sat, 09 Nov 2019 13:41:32 GMT", "via": "1.1 google", "alt-svc": "clear" } } ```

kerem commented

2026-02-27 20:22:39 +03:00

Author

Owner

@ramsayleung commented on GitHub (Nov 12, 2019):

Do you mean that the reqwest will hide the error message from the response, could you help me reproduce this case by doing it step by step?

@ramsayleung commented on GitHub (Nov 12, 2019): Do you mean that the `reqwest` will hide the `error` message from the response, could you help me reproduce this case by doing it step by step?

kerem commented

2026-02-27 20:22:39 +03:00

Author

Owner

@TimotheeGerber commented on GitHub (Apr 19, 2020):

I am only guessing here, but I think that @sputnick1124 tried to print the reqwest's Response with something like:

println!("{:#?}", response);

Unfortunately, the implementation of the Debug trait for Response does not show the body of the response, only the URL, status and headers (see the implementation here). It leads @sputnick1124 to believe that the JSON returned by Spotify is not in the Response. But it is. You can get the body with the .text(), .bytes() or even .json() methods.

@TimotheeGerber commented on GitHub (Apr 19, 2020): I am only guessing here, but I think that @sputnick1124 tried to print the `reqwest`'s `Response` with something like: ```rust println!("{:#?}", response); ``` Unfortunately, the implementation of the `Debug` trait for `Response` does not show the body of the response, only the URL, status and headers (see [the implementation here](https://github.com/seanmonstar/reqwest/blob/d4a88a8d35ba482ed5fc766666a3fff65c3ff746/src/async_impl/response.rs#L394)). It leads @sputnick1124 to believe that the JSON returned by Spotify is not in the `Response`. But it is. You can get the body with the `.text()`, `.bytes()` or even `.json()` methods.

kerem commented

2026-02-27 20:22:39 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Apr 20, 2020):

@TimotheeGerber is correct. I was naively just printing out the Response object and neglected to go look at it's implementation. I have a clear idea now of what I am trying to do. I'll work on a PR and get that up sometime this week.

Thanks, @TimotheeGerber!

@sputnick1124 commented on GitHub (Apr 20, 2020): @TimotheeGerber is correct. I was naively just printing out the `Response` object and neglected to go look at it's implementation. I have a clear idea now of what I am trying to do. I'll work on a PR and get that up sometime this week. Thanks, @TimotheeGerber!

kerem commented

2026-02-27 20:22:39 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Apr 23, 2020):

PR is open. Please provide any comments/suggestions for improvement.

@sputnick1124 commented on GitHub (Apr 23, 2020): PR is open. Please provide any comments/suggestions for improvement.

kerem referenced this issue

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

[PR #21] [MERGED] Feature fix devices #188