You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title: Tracks not returned for a user, even with blocked filter enabled
Issue found of: 13th May 2021
Endpoint(s):
GET /users/21350278/tracks
Scope(s):
Both:
None (application is not using authentication i.e., implicit flow)
User OAUTH
Steps to reproduce:
curl --request GET \
--url 'https://api.soundcloud.com/users/21350278/tracks?limit=200&linked_partitioning=true&client_id=DONT_SHARE_CLIENT_ID&access=playable,preview,blocked'
Expected behaviour:
A list of tracks, including tracks which are blocked.
Actual behaviour:
If called with no user OAuth scope, no tracks will be returned - however the tracks can be viewed on the user profile: https://soundcloud.com/adamtrxu/tracks
If called with a user OAuth scope, private tracks are returned, but none of the public tracks listed on the profile.
The question here is that the new high level metadata changes were made to enable us to view blocked tracks, but in this particular case, nothing is returned on the API (see #1)
The text was updated successfully, but these errors were encountered:
Hey @mgoodfellow . so, actually, you are seeing a "bug" in our API that's not exactly related to the access filter. The problem is actually that pagination is not taking into account the actual tracks returned, but rather the total tracks the user has. Since most are private tracks, the first 200 results are returned as an empty array. But notice there is still a next_href, which, when you call it, does return a few more tracks.
This is something we're already looking into how to fix, but for now, the best thing would be to rely on next_href to let you know whether or not you should request the next page of results. Does that make sense?
Ok thanks @anikarni - we shall change our integration to work around this issue for now with the above advice!
A future fix will be amazing as then the pagination can be owned by the front-end rather than the server side needing to eager load it all to make sure all the data is there during pages.
Title: Tracks not returned for a user, even with blocked filter enabled
Issue found of: 13th May 2021
Endpoint(s):
GET /users/21350278/tracks
Scope(s):
Both:
Steps to reproduce:
curl --request GET \ --url 'https://api.soundcloud.com/users/21350278/tracks?limit=200&linked_partitioning=true&client_id=DONT_SHARE_CLIENT_ID&access=playable,preview,blocked'
Expected behaviour:
A list of tracks, including tracks which are blocked.
Actual behaviour:
If called with no user OAuth scope, no tracks will be returned - however the tracks can be viewed on the user profile: https://soundcloud.com/adamtrxu/tracks
If called with a user OAuth scope, private tracks are returned, but none of the public tracks listed on the profile.
The question here is that the new high level metadata changes were made to enable us to view blocked tracks, but in this particular case, nothing is returned on the API (see #1)
The text was updated successfully, but these errors were encountered: