Skip to content

fix(webapi): fall back to pathfinder GraphQL for playlists that 404 - #754

Open
prefixFelix wants to merge 2 commits into
jpochyla:mainfrom
prefixFelix:pr4-playlist-partner
Open

fix(webapi): fall back to pathfinder GraphQL for playlists that 404#754
prefixFelix wants to merge 2 commits into
jpochyla:mainfrom
prefixFelix:pr4-playlist-partner

Conversation

@prefixFelix

Copy link
Copy Markdown
Contributor

Generated playlists like Daily Mix are no longer served via WebAPI, resulting in 404 errors.
Implemented a fallback that fetches playlists via api-partner (pathfinder GraphQL), if WebAPI requests returns 404.
So the WebAPI stays the primary source for loading playlists.

Playlists that 404 are remembered for the session. The detail page loads metadata and tracks separately, so without this both pay for the same 404 on every visit.

Comment on lines +1878 to +1882
// Only the metadata is wanted here, so ask for the smallest page of
// tracks pathfinder will give us.
if self.is_partner_playlist(id) {
return Ok(self.fetch_playlist(id, 0, 1)?.to_playlist());
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a better way to know which playlist paths we should use to load. Otherwise we have to make this temp query in order to know if the playlist is a partner one or not?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, im also not happy with the solution. Maybe we could first check if the id/owner of the playlist is spotify. I have to check that. We could also ditch the whole webapi for fetching playlists.

Comment on lines +1884 to +1890
match self.load(request) {
Err(Error::WebApiStatus(404)) => {
self.mark_partner_playlist(id);
Ok(self.fetch_playlist(id, 0, 1)?.to_playlist())
}
result => result,
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having an error decide how to load is a little bit odd.

@marcfusch

Copy link
Copy Markdown
Contributor

I testd your branch locally and noticed it fixed the 404 playlists.
But it does not fix the 403 ones that are currently the ones from other users, not from spotify themselves.
The 403 is documented as intentional in the OpenAPI schema for /playlists/{playlist_id}/items:
I dont want to open another PR but the fix is actually quite simple

@@ -1882,7 +1882,7 @@ impl WebApi {
         }
         let request = &RequestBuilder::new(format!("v1/playlists/{id}"), Method::Get, None);
         match self.load(request) {
-            Err(Error::WebApiStatus(404)) => {
+            Err(Error::WebApiStatus(404 | 403)) => {
                 self.mark_partner_playlist(id);
                 Ok(self.fetch_playlist(id, 0, 1)?.to_playlist())
             }
@@ -1919,7 +1919,7 @@ impl WebApi {
             .query("additional_types", "track");

         let result: Vector<PlaylistItem> = match self.load_all_pages(request) {
-            Err(Error::WebApiStatus(404)) => {
+            Err(Error::WebApiStatus(404 | 403)) => {
                 self.mark_partner_playlist(id);
                 return self.get_partner_playlist_tracks(id);
             }

Just let the fallback work for 403 responses too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants