87e5e1fa23
Root cause (from the reporter's app.log): a ListenBrainz weekly playlist syncs through the in-memory youtube_playlist_states discovery machine. When that live state is lost — a Docker restart, or the discovery process ending while the user waits for the media-server scan — the DB discover-download snapshot survives but the live state is gone. Every recovery action (Cancel/Reset/Delete) then hit `key not in states` and returned 404 "YouTube playlist not found" (hence the confusing "Youtube" on a ListenBrainz playlist), leaving the playlist permanently wedged with no way to dismiss or re-sync. Works for the maintainer because a single session with no restart keeps the live state alive. Fix — these are cleanup ops, so "the thing is already gone" is SUCCESS, not 404: - cancel_sync core (shared by YouTube + ListenBrainz + Tidal/Deezer/Qobuz/...) → missing key returns idempotent success. - reset_youtube_playlist / delete_youtube_playlist → same. The playlist becomes recoverable: Cancel/Reset clears the dead state and the user re-syncs fresh. Tests: cancel_sync core (missing key = idempotent 200 not 404; present key still cancels + clears the worker + reverts phase); endpoint-level idempotency for cancel/reset/delete; updated the old test that locked the 404 wedge. 834 sync/ discovery tests green. |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| beatport.py | ||
| deezer.py | ||
| endpoints.py | ||
| hero.py | ||
| listenbrainz.py | ||
| manual_match.py | ||
| matching.py | ||
| playlist.py | ||
| qobuz.py | ||
| quality_scanner.py | ||
| scoring.py | ||
| spotify_public.py | ||
| sync.py | ||
| tidal.py | ||
| youtube.py | ||