Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mgoodfellow opened this issue May 13, 2021 · 2 comments
Open
Labels
bug Something isn't working

Comments

@mgoodfellow
Copy link

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)

@anikarni
Copy link

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
Copy link
Author

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.

@rahul-sc rahul-sc added the bug Something isn't working label May 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants