3 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	d7a8e5f300	fix(library): a track delete that cannot remove its file deletes nothing — #3918 ... Two delete paths had opposite failure policies. tracks.RemoveTrack logged a failed os.Remove and deleted the row anyway, which CASCADEs likes, plays, playlist memberships and tags, while the file survived for the next scan to re-import as a stranger. library.DeleteTrackFile stopped correctly but reported it as a bare 500 nobody could read. One path now: library.DeleteTrackFile removes the file first and, on anything but ErrNotExist, returns *FileRemoveError with nothing deleted. Only then does it delete the row and tidy an emptied album and artist in one transaction, log the sync change and clear orphaned artist art. RemoveTrack calls it, which also fixes RemoveTrack never logging a sync change. Quarantine Delete file now tidies emptied albums and artists too. Both endpoints answer an unwritable library (EROFS, EACCES, EPERM) with 409 library_not_writable. The message names the directory (removal writes to the parent), the uid:gid the server runs as, and that nothing was deleted. Other remove errors are 500 file_delete_failed with the path. The reachable surface is quarantine Delete file, which failed silently: no copy for the code on either client, and Android swallowed the exception so the row just reappeared. Web and Android now have copy for both codes and append the server message for exactly those two. Android's quarantine screen shows it in a snackbar. DELETE /api/admin/tracks/{id} has had no client since f7278f24, which kept it on purpose for a safer admin surface, so its history loss was latent. Fixed rather than removed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ31KQpYbStyK5y58UmPLH	2026-09-11 14:23:01 -04:00
bvandeusenandClaude Opus 4.7	ee7f0cdb42	feat(#392): publish quarantine + playlist mutation events ... Slice 3a — extends the producer set onto the SSE bus. quarantine events (5 producer sites): - quarantine.flagged (user-side flag): broadcast so the flagger's other clients invalidate their Hidden tab and admins' clients invalidate their queue. - quarantine.unflagged (user-side unflag): scoped to the user. - quarantine.resolved / .file_deleted / .deleted_via_lidarr (admin actions): broadcast because a single admin action can affect every user who'd flagged that track. playlist events (6 producer sites): - playlist.created / .updated / .deleted: owner-scoped. - playlist.tracks_changed: emitted for AppendTracks / RemoveTrack / Reorder. Owner-scoped. Single kind for all three mutations because the client invalidation logic is identical (refetch the detail). Public-playlist subscribers (other users viewing someone else's public playlist) intentionally left out — needs a separate broadcast kind, not exercised yet at single-household scale. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 21:28:05 -04:00
bvandeusen	6fedd495be	feat(api): /api/quarantine user + admin endpoints + Service wiring ... User-facing /api/quarantine handlers (POST flag, DELETE unflag, GET mine) plus the five /api/admin/quarantine endpoints (queue, resolve, delete-file, delete-via-lidarr, actions). Mount() and the handlers struct now accept the lidarrquarantine.Service, constructed in server.go alongside the existing lidarrrequests wiring.	2026-04-30 20:19:39 -04:00