bvandeusenandClaude Opus 5
d7a8e5f300
test-go / test (push) Failing after 55s
test-web / test (push) Successful in 56s
test-go / integration (push) Failing after 4m50s
android / Build + lint + test (push) Successful in 5m52s
release / Build signed APK (releases and dev) (push) Successful in 6m5s
release / Build + push container image (push) Successful in 1m14s
release / Verify release artifacts (tag releases only) (push) Skipped
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
59 lines
2.1 KiB
Go
59 lines
2.1 KiB
Go
package api
|
|
|
|
import (
|
|
"errors"
|
|
"fmt"
|
|
"log/slog"
|
|
"net/http"
|
|
|
|
"git.fabledsword.com/bvandeusen/minstrel/internal/apierror"
|
|
"git.fabledsword.com/bvandeusen/minstrel/internal/library"
|
|
)
|
|
|
|
// fileRemoveAPIError answers a delete that could not reach the track's file
|
|
// (#3918). Both delete endpoints use it, so the operator gets the same
|
|
// explanation from the admin remove-track action and from quarantine's Delete
|
|
// file.
|
|
//
|
|
// The unwritable case is a 409 rather than a 500 because nothing is broken: the
|
|
// request conflicts with how the library is mounted, and the fix is the
|
|
// operator's. The message names the directory — removal writes to the parent,
|
|
// not the file — and the uid/gid the process runs as, which is the half of a
|
|
// permission problem invisible from the host. Every case says nothing was
|
|
// deleted, because that is exactly what the operator will be worried about.
|
|
func fileRemoveAPIError(err error) (*apierror.Error, bool) {
|
|
var fre *library.FileRemoveError
|
|
if !errors.As(err, &fre) {
|
|
return nil, false
|
|
}
|
|
if fre.NotWritable() {
|
|
return &apierror.Error{
|
|
Status: http.StatusConflict,
|
|
Code: "library_not_writable",
|
|
Message: fmt.Sprintf(
|
|
"Minstrel runs as uid %d, gid %d and cannot delete from %s (%s). "+
|
|
"The library mount must be writable by that user. Nothing was deleted.",
|
|
fre.UID, fre.GID, fre.Dir(), fre.Reason()),
|
|
Cause: err,
|
|
}, true
|
|
}
|
|
return &apierror.Error{
|
|
Status: http.StatusInternalServerError,
|
|
Code: "file_delete_failed",
|
|
Message: fmt.Sprintf("Could not delete %s (%s). Nothing was deleted.", fre.Path, fre.Reason()),
|
|
Cause: err,
|
|
}, true
|
|
}
|
|
|
|
// logFileRemoveFailure records a delete that could not reach its file. An
|
|
// unwritable library is an environment fact the operator can fix, so it is a
|
|
// Warn; anything else is a real fault.
|
|
func logFileRemoveFailure(logger *slog.Logger, apiErr *apierror.Error, attrs ...any) {
|
|
attrs = append(attrs, "code", apiErr.Code, "err", apiErr.Cause)
|
|
if apiErr.Status == http.StatusConflict {
|
|
logger.Warn("api: track file could not be deleted", attrs...)
|
|
return
|
|
}
|
|
logger.Error("api: track file could not be deleted", attrs...)
|
|
}
|