Reordering is incorrect when duplicate URIs exist #15

New issue

Open

opened 2026-08-22 20:31:08 +00:00 by faceguy · 0 comments

faceguy commented

2026-08-22 20:31:08 +00:00

Owner

ReorderPlaylistTracks() stores only one current index per URI. Each duplicate occurrence overwrites the preceding occurrence in indexMap.

For some duplicate orders, the lookup returns an index before the current destination position. The local shifting loop at /internal/spotify/playlist.go#L203 handles only targetIndex > i, so it can overwrite entries in its local representation and issue subsequent reorder requests with incorrect positions.

Using original order [A, B, A, C, A] and desired order [A, A, A, B, C] against a Spotify-shaped test server, the function returned success but corrupted its local order to [A, A, A, A, C].

`ReorderPlaylistTracks()` stores only one current index per URI. Each duplicate occurrence overwrites the preceding occurrence in `indexMap`. For some duplicate orders, the lookup returns an index before the current destination position. The local shifting loop at `/internal/spotify/playlist.go#L203` handles only `targetIndex > i`, so it can overwrite entries in its local representation and issue subsequent reorder requests with incorrect positions. Using original order `[A, B, A, C, A]` and desired order `[A, A, A, B, C]` against a Spotify-shaped test server, the function returned success but corrupted its local order to `[A, A, A, A, C]`.

faceguy added the

bug

label

2026-08-22 20:31:08 +00:00

faceguy self-assigned this

2026-08-22 20:31:08 +00:00