Failed Add Item To Play Queue

[SmoothDagger]

Plan

Premium

Country

US

Device

Desktop PC

Operating System

Windows 11

PREFIX: My account was started yesterday & set to the single-user monthly premium account.

Apologies, this question keeps getting flagged as spam when I add links to various APIs so I will just leave everything bold instead of using links.

My Question or Issue

I have a Godot desktop application that I added Spotify to. I've been able to successfully execute various Spotify REST APIs, such as Getting Available Devices & Searching for an Item, returning either 200, 202, or 204 success codes using Godot's HTTP Request class. However, I keep failing POST calls to APIs that require the 'user-modify-playback-state' authorization scope, e.g., Add Item to Playback Queue. Do note that I already have other entire HTTP API suites (e.g., Twitch APIs) implemented & working currently using GETs, POSTs, PUTs, & DELETEs in this application.

I have granted access to the application with Spotify's application authorization redirect page & confirmed it is listed under my Spotify account.

Current Authorization Scopes:

• user-modify-playback-state
• user-read-currently-playing
• user-read-playback-state
• user-read-private

This has resulted in an authorization code that I was able to use for retrieving an access token that verified the authorization scopes I used, via., the Request an Access Token response. All requested authorization scopes were included in the "scope" response body in the spaced format, e.g.,

           "user-modify-playback-state user-read-currently-playing user-read-playback-state user-read-private"

With respect to Add Item to Playback Queue, & subsequent APIs that require the user-modify-playback-state, this is resulting in an error code from Godot's HTTP Request class that signals I do not have write access since adding an item to the playback queue is a POST request. If I change the Add Item to Playback Queue request to a GET request, it will succeed with a 200-success code as if I attempted to use Get the User's Queue, as they share the same base endpoint. I presume the Uri that is required for the Add Item to Playback Queue endpoint is discarded when making the GET request. Using the correct POST HTTP request, the resulting headers & body for the call to Add Item to Playback Queue are empty with an HTTP response code of 0, not even a 4XX error code. I am uncertain why I am getting a write access error when my access token was approved for user-modify-playback-state.

I have the HTTP request being sent out to Add Item to Playback Queue API after a search item has been successfully retrieved from the Searching for an Item API. I tested a Uri retrieved from the Searching for an Item API on the documentation page 'Try' section of the Add Item to Playback Queue API, which successfully added the track to my Spotify queue. The subsequent Add Item to Playback Queue API fails in the application with the Godot error & a response code of 0.

Is there any inclination of what I may be doing incorrectly?

The biggest flag here is that I already have 40+ Twitch HTTP APIs working correctly with POSTs, GETs, & DELETEs. I do not think this is an error within Godot or my application's HTTP set up. My biggest inclination is thinking that my account is not approved for user-modify-playback-state authorization or that it's because my Spotify account was started yesterday with premium. I do know the Add Item to Playback Queue API I am trying to access requires an account to have premium.

Things I've verified:

• Ensured Add Item to Playback Queue API endpoint Uri is correct.
• Ensured authorization scopes included user-modify-playback-state.
• Removed authorization of the application, requested a new authorization code, re-authorized the application for account access, & requested a new access token with the new authorization code.
• Successfully tested other endpoints that did not require user-modify-playback-state authorization scope & received 2XX success codes.
• Verified ability to queue up a song correctly with a retrieved search item Uri through the test API on the Add Item to Playback Queue API documentation page.
• Verified application was approved for access on my Spotify account, e.g., Manage Apps in Spotify.

[Ximzend]

Hi SmoothDagger,

Do you have implemented an Authorization code flow?

[SmoothDagger]

Hey there, Ximzend!

Yes! I do use the normal authorization code flow.

It's a little rigid at the moment since I'm still testing:

OS.ShellOpen(
            uri: $"https://accounts.spotify.com/authorize?" +
                  $"client_id={m_spotifyData.ClientId}&" +
                  $"response_type=code&" +
                  $"redirect_uri={c_redirectUri}&" +
                  $"scope={Uri.EscapeDataString(c_userAccessScopes)}"
);

This opens up the authorization window in the browser, including giving permissions to the app, if necessary, & retrieving the long authorization code string that's returned in the Uri, e.g., code=asdasdas....20221asda. I use the returned authorization code to retrieve an access token:

var headers = new string[]
{
          $"Content-Type: application/x-www-form-urlencoded",
          $"Authorization: Basic {Convert.ToBase64String(inArray: Encoding.UTF8.GetBytes(s: $"{m_spotifyData.ClientId}:{m_spotifyData.ClientSecret}"))}"
};
m_httpManager.SendHttpRequest(
          url: $"{c_urlAccessToken}",
          headers: headers,
          method: Method.Post,
          json:
                  $"grant_type=authorization_code&" +
                  $"code={c_authorizationCode}&" +
                  $"redirect_uri={c_redirectUri}",
          requestCompletedHandler: OnRequestAccessTokenCompleted
);

At this point, I receive a 200-success code from Spotify with a body containing all the information, .e.g., access token, refresh token, scopes I've been approved for, etc. I use the access token sent down for all my API calls. The approved scope contains the user-modify-playback-state.

Cheers,

Jason

[SmoothDagger]

Hi all,

I've also tried furthering this investigation. Rather than using a search result, I sampled the Uri that is provided in the Add to Queue API, namely: 

https://api.spotify.com/v1/me/player/queue?uri=spotify%3Atrack%3A4iV5W9uYEdYUVa79Axb7Rh

This also fails using the following HTTP call with a 0-response code & the Godot error code of "Request failed due to connection (read/write) error":

var headers = new string[]
{
          $"Authorization: Bearer {m_spotifyAccessToken.AccessToken}",
};
m_httpManager.SendHttpRequest(
          url: $"https://api.spotify.com/v1/me/player/queue?uri=spotify%3Atrack%3A4iV5W9uYEdYUVa79Axb7Rh",
          headers: headers,
          method: Method.Post,
          json: string.Empty,
          requestCompletedHandler: OnTrackQueueCompleted
);

The access token I have 100% works as I was able to make a successful call to the Search API & proceeded to fail when I put in a dummy access token, e.g., "Authorization: Bearer Q" or completely removed the header.

Further steps include:

• Adding the application as an exception to the Windows Firewall.
• Disabling Windows Firewall for both private & public.
• Removing the user-read-private access scope & generating a new authorization code & access token.

I'm still at a loss for what I may be doing incorrectly & why the Godot HTTP request would signal that there's a connection issue.

Cheers,

Jason

[Ximzend]

Thank you for the detailed explanation. Sadly I don't have knowledge about Godot.

I read your initial post again and saw the app was already listed in your account, so it is no authorization issue.

Does Get Playback State work?

[SmoothDagger]

Hi Ximzend,

Not a problem! I only reference Godot because the application is built in Godot & uses Godot's own HTTP Request object to handle web calls. I've used the built-in web requests successfully for accessing tons of endpoints using the Twitch APIs, so I don't think it's Godot's web requests that are failing here. I haven't seen this error code for a Godot connection issue once; It's almost like it's blocking the web request before it's even sent. These error codes are not the web response error codes like 401, 404, etc.

With respect to Get Playback State, I'm able to reach the endpoint. I receive both the 200 & 204 response codes, depending on whether the Spotify player is active or not, respectively. I'm also able to reach the Get Available Devices API endpoint, which I tried using the device_id that's returned as the optional device_id parameter that can be included in the Add to Queue API.

My inclination is that I am being denied server access on Spotify's end for queuing songs. I read something on CORS issues when making web requests, but since my application is just a desktop application & not a web browser, I'm not certain where to find the output of that information. I presume Spotify supports desktop applications with web requests, especially since I've made other successful requests.

Cheers,

Jason

[SmoothDagger]

Hi all,

Furthered some investigations. I was able to successfully make calls using Postman & songs were added to my Spotify queue. Are there some special requirements for desktop applications? It doesn't make much sense that Postman is able to reach the API successfully as an application but mine cannot. I'm at a complete loss on why my application would be failing these calls if I'm using the same Uri & I'm able to make calls to other Spotify APIs.

I added a few screenshots from the application.

1. The approval & access granting that pops up after launching the application. Note: this contains controlling Spotify on devices, which is the requirement for queuing up songs, as far as I'm aware.
2. The access token I'm receiving. As far as I saw in the documentation, these are the correct formatting, e.g., Content-Type: application/x-www-form-urlencoded & Authorization: Basic {client_id}:{client_secret}.ToBytes().
3. The API request that is sent to the Queue to Playlist in a red outlined box. This is the call that is made after a successful search response from Spotify with the first track found. I've tested the same search result with the complete endpoint in Postman & it works just fine.

Cheers,

Jason

[Ximzend]

I've found these documentation pages with different code then yours:

https://docs.godotengine.org/en/stable/tutorials/networking/http_request_class.html

https://docs.godotengine.org/en/stable/classes/class_httprequest.html

[SmoothDagger]

Hi Ximzend,

Nice to see you again!

With respect to different code, are you referring to GDScript vs C#? In each of the code sections, it has samples for each one; by default, it's set to GDScript. There are a few buttons at the top that allow you to switch between the two languages.

I do have multithreading set up, so in the above samples, you'll notice it calls m_httpManager.SendHttpRequest(), which allows for Godot's Nodes to be handled on the main thread. All HttpRequests inherit from Godot's Node class, the fundamental type of Godot objects, which requires it to be added in the Node tree for execution. My HttpManager processes these on the main thread & adds them to the Node tree for execution.

The Http Requests have the same data that is provided in the Godot documentation you provided, e.g.,

• Uri
• Headers
• Type of Http Request (PUT, GET, POST, etc.)
• Body information (which is not required for this POST, as far as I can tell.)
• Callback method (which is the same as the OnCompletion event, except that this is queued into the HttpManager & needs reference of it).

I provided some additional context through a few code snippets:

This is the HttpManager receiving a send call from a different object, e.g., m_httpManager.SendHttpRequest(), & queuing it up for processing for the main thread. All HttpRequests are nodes, as stated above, & require execution from the main thread.

This is the HttpManager processing each queued HttpRequest that we've added from SendHttpRequest from a separate thread now on the main thread Godot uses. The AddChild function is adding the HttpRequest object to the scene hierarchy in Godot for main thread processing, a requirement for the HttpRequest objects to dispatch, as they derive from the fundamental Godot object type Node.

 

The toughest part of this is that this works for every single Twitch API, & subsequently every other Spotify API, with no issues whatsoever. I can do GETs, POSTs, PUTs, & DELETEs. The one thing I saw for potential Spotify issues is what's referred to as CORS, which I'm not certain if my application is being blocked from Read/Writing on the Spotify servers & would correlate with the Godot Http Error Code I'm receiving: RESULT_CONNECTION_ERROR that states "Request failed due to connection (read/write) error."

I'm still further investigating this, but this is getting very difficult, very quickly. Postman allowed my POST to queue up a song. I used the same link I retrieved from the above snippet of the OnTrackSearchCompleted & it worked just fine, along with actually using the built in Try button on the Add Track to Playback Queue documentation page. So essentially, I have the correct information for queuing up the track in my application. The lack of Http Response code & actually being a Godot Error Code signals to me that this application is being blocked by Spotify & not something on my end.

Is it possible I did not do something with registering the application correctly? I have the screenshot above where this application was added to my account, as far as I'm aware. 

Cheers,

Jason

[Ximzend]

Thank you for the detailed explanation. This way I can learn Godot from you 🙃

[SmoothDagger]

Hi Ximzend,

Ha, I'm not sure you want to 😅 open source is open sores. 

Cheers,

Jason

[SmoothDagger · Accepted solution]

Hi all,

I just wanted to update this with the solution. At the time of writing this, all versions of Godot for 4.X up to 4.2.2 & 4.3 beta incur an Http Request failure when sending a POST call with 0 bytes of information. 

The header of Content-Length is not appended to the Godot HttpRequest headers automatically when a POST is sent to an endpoint with a body length of 0 & requires manual insertion in the headers for the built-in Godot HttpRequest class, e.g., "Content-Length: 0," in order to properly send.

This was not an error from Spotify APIs, only the Godot Engine. I am able to successfully make POST calls now that I've manually added "Content-Length: 0" to the headers when there is no information being sent up. 

Cheers,

Jason