Repro (as of e5f589d):
Have a Spotify playlist with several tracks. (All these tracks should have been added by the owner account according to the Spotify API). Change the Playlists DB filename to something new and request POST /admin/load-ids to initialize it. View this playlist in the frontend, logged in as any account other than the owner account. All the tracks should have addedBy be the owner account name. Add a new track. When you confirm, the app will crash.
Explanation:
The current implementation of initializePlaylist being called by the POST /admin/load-ids endpoint uses the Spotify API added_by to initialize the db addedBy. In this case the owner account id was used. Currently the frontend requests display names in usePlaylistData for all the user ids it finds in the playlist's tracks[].addedBy, which in this case was only the owner account. After submitting the app starts requesting the playlist again, but the old version of the addedByUsers resource is unchanged instead of set to loading. So when the playlist fetch is resolved and the app tries to rerender (before the addedByUsers fetch is resolved), it tries to get the new track's addedBy's display name and fails.
I will not fix this directly. #38 should fix this by including the display names of ALL the playlist's users, and thus all possible addedBy-s, in the one playlist fetch. But it's important to know this is broken until then.
Repro (as of e5f589d): Have a Spotify playlist with several tracks. (All these tracks should have been added by the owner account according to the Spotify API). Change the Playlists DB filename to something new and request
POST /admin/load-idsto initialize it. View this playlist in the frontend, logged in as any account other than the owner account. All the tracks should haveaddedBybe the owner account name. Add a new track. When you confirm, the app will crash.Explanation: The current implementation of
initializePlaylistbeing called by thePOST /admin/load-idsendpoint uses the Spotify APIadded_byto initialize the dbaddedBy. In this case the owner account id was used. Currently the frontend requests display names inusePlaylistDatafor all the user ids it finds in the playlist'stracks[].addedBy, which in this case was only the owner account. After submitting the app starts requesting the playlist again, but the old version of theaddedByUsersresource is unchanged instead of set to loading. So when the playlist fetch is resolved and the app tries to rerender (before theaddedByUsersfetch is resolved), it tries to get the new track's addedBy's display name and fails.I will not fix this directly. #38 should fix this by including the display names of ALL the playlist's users, and thus all possible addedBy-s, in the one playlist fetch. But it's important to know this is broken until then.