5 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
bvandeusen	ef3fffb3ea	fix(lidarrquarantine): keep LidarrAlbumMbid nil on Resolve/DeleteFile audit rows + cover idempotent Resolve ... The audit log treats lidarr_album_mbid as a 'this row triggered Lidarr' marker. Setting it on Resolve/DeleteFile (where Lidarr is never contacted) muddied that semantic. Reverting to plan: only DeleteViaLidarr writes the mbid. Adds an idempotency test for Resolve over a track with zero rows (audit row written, affected_users=0, mbid nil).	2026-04-30 19:42:19 -04:00
bvandeusen	782e72b595	feat(lidarrquarantine): admin actions Resolve/DeleteFile/DeleteViaLidarr	2026-04-30 19:37:40 -04:00
bvandeusen	7a0bc1f815	fix(lidarrquarantine): translate FK violation to ErrTrackNotFound + drop unneeded *string AlbumTitle ... - Flag now detects Postgres SQLSTATE 23503 (foreign_key_violation) on UpsertQuarantine and surfaces ErrTrackNotFound instead of a wrapped generic. T8's handler can now return 404 track_not_found cleanly. Constraint-name guard ('track' substring) keeps a future user_id FK from mis-mapping to the same error. - AdminQueueRow.AlbumTitle is now string (not *string). albums.title is NOT NULL upstream; the empty-string-to-nil dance was answering a nullability question that doesn't exist in the schema. - Add TestFlag_NonexistentTrackReturnsErrTrackNotFound covering the new branch.	2026-04-30 17:42:55 -04:00
bvandeusen	b4fe224a67	feat(lidarrquarantine): Service Flag/Unflag/ListMine/ListAdminQueue	2026-04-30 17:36:27 -04:00