Repository navigation
bug(catalog): re-importing a previously trashed track places new import in trash #43
Description
Summary
If a track is moved to trash and then the same URL is imported again, the new import inherits the trash placement from the old entry. The new track appears in Trash instead of the Library.
Root cause
addTrackToLibrary() calls replaceTrackId(existingId, newId) when a duplicate source URL is found. This migrates the old entry's folder placement (including Trash) to the new ID. When the old track was in Trash, the new track was placed in Trash too.
Fix
addTrackToLibrary() now checks whether the existing matching track is in the Trash folder. If so, the old entry is fully removed (not used as a placement anchor) and the new import is added to the Library as normal.
Release
0.5.0-alpha.1
Activity
thcp commentedon May 17, 2026
Fixed three interlocking bugs: (1) loadState() was calling purgeTrash() on every startup, auto-wiping trash before syncWithServer ran; replaced with orphan-ref cleanup only. (2) syncWithServer() now skips job IDs that are already in the trash folder, preventing re-import of soft-deleted tracks. (3) Empty trash button now fires DELETE /api/jobs/{id} for each purged track so the server removes the job directory and registry entry — preventing the job from being returned on next sync.
feat(ui-refactor): DAW redesign, library overhaul, sections, analysis…