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

[prefixFelix]

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.

[jacksongoode]

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?

[prefixFelix]

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.

[jacksongoode]

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

[marcfusch]

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

[jacksongoode]

I think this seems good, I'd like to merge @prefixFelix any reason we shouldn't?

[prefixFelix]

Yeah, I'm still looking into ways to improve the code. The findings from @marcfusch are interesting. I didn't notice that some playlists still fail. It seems that playlists from other people where you don't collaborate (read only) throw the 403 errors.
So in general, playlists we can write to can be fetched via the WebAPI, while ones we can only read must be fetched via the partner API. main problem is that we can't cleanly distinguish between the two types before fetching the content of a playlist, because the collaborative field in v1/me/playlists seems inconsistent. So I currently see no option to say, before fetching, whether a playlist would need to be fetched via WebAPI or partner.

I see two options:
#A Only use the partner API for playlists and drop the WebAPI. Shitty because the partner API isn't as reliable.
#B Keep both the WebAPI and the partner approach, but force which one to prefer based on the source that delivers the playlist: Home -> partner, Saved playlists -> WebAPI

[marcfusch]

Yes the affected playlist are the user made ones in read only (basically every playlist since by default Spotify opts the user in for their playlists to be public)

As for the implementation option, B should be a better way to go forward since there is at least one official documented way, and the more unofficial for fallback / the playlist types known to not work with.

Maybe separating the code for the old webapi and the new pathfinder graphic shenanigans into different files to make the whole thing more readable since it has been a long time I have seen psst's codebase and with all of your commits it seemed a bit complex.