Announcements

Help Wizard

Step 1

NEXT STEP

FAQs

Please see below the most popular frequently asked questions.

Loading article...

Loading faqs...

VIEW ALL

Ongoing Issues

Please see below the current ongoing issues which are under investigation.

Loading issue...

Loading ongoing issues...

VIEW ALL

duration_ms suddenly returning float instead of int

Solved!

duration_ms suddenly returning float instead of int

Suddenly, the api.spotify.com/v1/tracks/{id} endpoint has started giving me track duration_ms as a float e.g.

"duration_ms": 2345.0,

The endpoint always used to return an int, which matches the documentation. Weirdly the response from the "try it" response sample still returns an int, but I think all that shows is how useless that thing is.

 

Reply

Accepted Solutions
Marked as solution

We believe it is fixed now, when I am trying it is returning integers as intended.

 

An optimization in the deserialization of JSON in upstream was causing the serializer to default to double types for integer values. The optimization was not applied to all queries, and several tools were sanitizing the response which was the reason we did not uncover this from the start. 

 

Are you able to confirm that it is working as intended for you now?

View solution in original post

23 Replies

The same problem started happening yesterday with disc_number, track_number, popularity, and image height/width in the track API

Interesting, I don't think I saw the same thing for track and disc number but I also added code to handle it there too, just in case. But maybe I need to go back and protect the image dimensions also. Urgh, what a waste of time.

You are 100% right, it's all the ints on the track object.

 

{"album":{"album_type":"album","artists":[{"external_urls":{"spotify":"https://open.spotify.com/artist/74XFHRwlV6OrjEM0A2NCMF"},"href":"https://api.spotify.com/v1/artists/74XFHRwlV6OrjEM0A2NCMF","id":"74XFHRwlV6OrjEM0A2NCMF","name":"Paramore","type":"artist","uri":"spotify:artist:74XFHRwlV6OrjEM0A2NCMF"}],"external_urls":{"spotify":"https://open.spotify.com/album/6tG8sCK4htJOLjlWwb7gZB"},"href":"https://api.spotify.com/v1/albums/6tG8sCK4htJOLjlWwb7gZB","id":"6tG8sCK4htJOLjlWwb7gZB","images":[{"url":"https://i.scdn.co/image/ab67616d0000b273f633b71861897348253993f4","width":640.0,"height":640.0},{"url":"https://i.scdn.co/image/ab67616d00001e02f633b71861897348253993f4","width":300.0,"height":300.0},{"url":"https://i.scdn.co/image/ab67616d00004851f633b71861897348253993f4","width":64.0,"height":64.0}],"is_playable":true,"name":"This Is Why","release_date":"2023-02-10","release_date_precision":"day","total_tracks":10.0,"type":"album","uri":"spotify:album:6tG8sCK4htJOLjlWwb7gZB"},"artists":[{"external_urls":{"spotify":"https://open.spotify.com/artist/74XFHRwlV6OrjEM0A2NCMF"},"href":"https://api.spotify.com/v1/artists/74XFHRwlV6OrjEM0A2NCMF","id":"74XFHRwlV6OrjEM0A2NCMF","name":"Paramore","type":"artist","uri":"spotify:artist:74XFHRwlV6OrjEM0A2NCMF"}],"disc_number":1.0,"duration_ms":206700.0,"explicit":false,"external_ids":{"isrc":"USAT22215020"},"external_urls":{"spotify":"https://open.spotify.com/track/7HdXRMw14roDx2a0COWk3M"},"href":"https://api.spotify.com/v1/tracks/7HdXRMw14roDx2a0COWk3M","id":"7HdXRMw14roDx2a0COWk3M","is_local":false,"is_playable":true,"name":"This Is Why","popularity":71.0,"preview_url":"https://p.scdn.co/mp3-preview/6bef3c7dbde272bb72ea41bd3c41ee509dab94fe?cid=f88ee52f92724d51b7579a1d1cdb3128","track_number":1.0,"type":"track","uri":"spotify:track:7HdXRMw14roDx2a0COWk3M"}

But weirdly, this doesn't impact PlaylistTrackObjects. Now I need to go and check the other track types.

I tried to curl, and I tried using the console on developer.spotify.com, and got this.. 

...
"disc_number" : 1,
"duration_ms" : 206700,
"explicit" : false,
"external_ids" : {
"isrc" : "USAT22215020"
},
"external_urls" : {
"spotify" : "https://open.spotify.com/track/7HdXRMw14roDx2a0COWk3M"
},
"href" : "https://api.spotify.com/v1/tracks/7HdXRMw14roDx2a0COWk3M",
"id" : "7HdXRMw14roDx2a0COWk3M",
...



I don't see this float behavior.. does curl give you the same thing? What are you using to do the web requests?

Everything way I have tried (curl, wget, Python Requests) returns floats, except the developer console. Perhaps I wasn't clear previously, but I already mentioned the developer console (they don't seem to call it that anymore after stripping most of its functionality) still returns ints:

 

> Weirdly the response from the "try it" response sample still returns an int

 

My guess is they sanitise/prettify the response data before displaying it in their "developer console" and in the process, hide the problem. I can also believe that not everyone gets the same API responses, there is evidence they roll changes out gradually.

 

They've actually had this same problem in other parts of the API already, see
* https://community.spotify.com/t5/Spotify-for-Developers/Get-Artist-reference-bug-receiving-Float-ins...

* https://community.spotify.com/t5/Spotify-for-Developers/The-response-type-of-artist-endpoint-is-mark...

Other points have had the same problem for months now....

Others on my team were seeing this issue for 24 hours before my requests started returning floats, so it’s definitely a gradual rollout. 

I saw the same thing with the developer console masking the issue. This issue is causing real problems for SDKs that expect integers but receive floats and thus can’t deserialize the JSON response correctly. 

Seeing an increase of this too. Love to see undisclosed API changes that breaks the functionality of strongly typed applications. 

Rolling out a patch breaks it for everyone where the change is not yet made. 

Please fix the issue and help the developers.

Also experiencing this issue!

This is a huge issue for typed languages, as we cannot fit floating point numbers in integers without spitting errors...

This is happening to me too! Limit and Offset on Get Album Tracks are returning as float instead of int. These fields do not need float granularity.

Good catch, I'll have to check my application, it might fall over on that (for really, really long albums)

 

Where on earth are these super hard working Spotify devs? Not even an acknowledgement.

Would you mind sharing an ID you are using in this query?

 

Our upstream is typed and returning integers, it shouldn’t be possible to get floats. But there are a bunch of you saying this is happening so I am really keen on reproducing it. 

This happens with any ID but here's an example with Postman for this Track ID 2O4Bb2WCkjlTPO827OnBMI
And the resulting images have the resolution dimensions as numbers in floating point, but all number values are that way now. No longer integers.

SLAzurin_0-1709367100531.png

 

In developer console it looks alright (but some already said that was the case):

LambertSpot_0-1709370661708.png

I tried to do a curl as well, and this time I was getting floats as well:

LambertSpot_1-1709370965011.png

I checked with our upstream, and it looks like it is returning floats when it shouldn't. I'll reach out to them with this and hopefully we can get this sorted asap.

great. Thanks. it would be interesting to understand why, given that it should be impossible on account of your typing, and presumably you've got some tests...

Here's a screenshot showing what I'm working with. You can see the json decode is failing because I am expecting an integer for limit but getting a float. The documentation still says this should be an integer. https://developer.spotify.com/documentation/web-api/reference/get-an-albums-tracks

 

kristinvidi_0-1709521116582.png

Using Postman gives me the same result and even shows that all int fields are now floats (limit, offset, total, disc_number, track_number, duration_ms).

kristinvidi_0-1709575728675.png

 

Marked as solution

We believe it is fixed now, when I am trying it is returning integers as intended.

 

An optimization in the deserialization of JSON in upstream was causing the serializer to default to double types for integer values. The optimization was not applied to all queries, and several tools were sanitizing the response which was the reason we did not uncover this from the start. 

 

Are you able to confirm that it is working as intended for you now?

Suggested posts