search

soundcloud / api

A public repo for our Developer Community to engage about bugs and feature requests on our Public API
148 stars 24 forks source link

Tracks not returned for a user, even with blocked filter enabled #55

Open mgoodfellow opened 3 years ago

mgoodfellow commented 3 years ago

Title: Tracks not returned for a user, even with blocked filter enabled

Issue found of: 13th May 2021

Endpoint(s):

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 https://github.com/soundcloud/api/issues/1)

anikarni commented 3 years ago

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?

mgoodfellow commented 3 years ago

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.