Playlist ID type is different from API spec

tpy

Hi, I'm having the same issue I reported in the following thread:

https://community.asti.ga/discussion/689/asti-ga-developers-returns-404

The issue is that the type of "id" field of "playlist" is number while it is supposed to be string based on the API reference.

This is one of the actual returned value:

 {

  "id": 21982455, # This is supposed to be string, but actually number.

  "owner": "user@example.com",

  "name": "Reference",

  "public": false,

  "songCount": 378,

  "coverArt": 26842406,

  "created": "2024-10-13T08:44:15"

 },

This script can reproduce the issue:

import requests
import json


base_url = "https://play.asti.ga/rest/"
username = "user@example.com" # To be changed
password = "password"         # To be changed
client_name = "my_client"
version = "1.16.0"

token = password.encode('utf-8').hex()

params = {
    'u': username,
    'p': f"enc:{token}",
    'v': version,
    'c': client_name,
    'f': 'json'
}

response = requests.get(f"{base_url}getPlaylists", params=params)
playlists = response.json().get('subsonic-response', {}).get('playlists', {}).get('playlist', [])

print(json.dumps(playlists, indent=2))

Which information should I rely on? If a root cause is not clear on Astiga side, I will consider to expect both string and number for this field.

Thanks!

gravelld

Hmmmm. It appears our IDs are all numbers, not strings. Is this not something you've noticed before?

Ah - I think I've not noticed it because generally we use XML in the Astiga app and these are passed as attributes, so they can always be parsed as strings.

I suppose we should change this to strings for JSON responses.

For now, can you just make this tolerant of being a number and just do a "" + number to assign it to your model?

tpy

Thanks, actually It had been "string" in the past, at least when I started the development.

And it was changed to "number" (when I submitted the first issue here), but back to "string" again.

Recently I'm seeing it in "number" again...

It appears that the server returns a nondeterministic type for the id field, which is very odd tho.

For now I have modified my code to accept both string and number. So this is resolved now.

gravelld

It's very odd that it is non-deterministic. I have a hunch this is down to our upgrade from PHP 7.4 to 8, and for a while we were oscillating between the two, but we're settled on 8 now so it should be stable.

tpy

That is very likely. Then the API doc should be updated if number type is expected.

Thanks!

xxubiqts

Just flagging a related issue detailed here: https://github.com/jeffvli/feishin/issues/795

gravelld

It's exactly the same issue... We'll look into it.

gravelld

This has been released.