Skip to content
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

Get Player Error Reasons #63

Closed
sputnick1124 opened this issue Nov 9, 2019 · 5 comments
Closed

Get Player Error Reasons #63

sputnick1124 opened this issue Nov 9, 2019 · 5 comments

Comments

@sputnick1124
Copy link
Contributor

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 #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.

@sputnick1124
Copy link
Contributor Author

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"
    }
}

@ramsayleung
Copy link
Owner

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?

@TimotheeGerber
Copy link
Contributor

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.

@sputnick1124
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants