Leftover-folder cleanup is skipped silently when the item is not tracked in Radarr/Sonarr

[enoch85]

Summary

When an item is not tracked in Radarr/Sonarr, the arr action handlers fall back to deleting the media file through the media server. The leftover-folder cleanup is never invoked on that path, so the media file is removed while the folder (subtitles, trailers, nfo, artwork) stays behind. Nothing is logged to say the cleanup was skipped, so with the option enabled it silently does not run.

Where

folderCleanup.cleanupAfterDelete is only called inside the Radarr-tracked UNMONITOR_DELETE_ALL branch:

• apps/server/src/modules/actions/radarr-action-handler.ts#L143-L150 - cleanup runs here
• apps/server/src/modules/actions/radarr-action-handler.ts#L201-L207 - "not found in Radarr" fallback calls mediaServer.deleteFromDisk() and returns, no cleanup, no warning

The Sonarr handler has the same shape at apps/server/src/modules/actions/sonarr-action-handler.ts#L117-L119.

Why it is not a one-line fix

collectCleanupInputs derives every fence the cleanup needs from Radarr (apps/server/src/modules/actions/radarr-action-handler.ts#L233-L272):

• rootFolderPaths - the roots it may act inside
• deletedFilePaths - proof the folder is the one just emptied
• otherItemPaths - the other movie folders it must not touch

With no arr entry, none of those are available, so the cleanup cannot simply be called from the fallback branch. Doing so without fences would mean an unfenced fs.rm.

Options

1. Derive the fences from the media server instead: the item's own file paths, the library root folders, and the sibling item paths for the "do not touch another item's folder" fence.
2. If (1) is out of scope for now, log a warning in the fallback branch so a skipped cleanup is visible rather than silent.

Observed

Jellyfin 10.11.11, collection type movie, arrAction = UNMONITOR_DELETE_ALL, cleanupLeftoverFolders = 1:

[RadarrActionHandler] Couldn't find movie in Radarr using resolved external IDs [TMDB:763164] for media server ID 9614097b... Attempting to remove from the filesystem via media server.
[JellyfinAdapterService] Successfully deleted Jellyfin item 9614097b... from disk

The media file was removed, the folder was left in place, and no cleanup line was logged.

[enoch85]

Investigated against the real stack. The premise of this issue is wrong for Jellyfin and Emby, and the log line from #3371 repeated the mistake, so PR #3373 corrects both rather than implementing option 1.

Jellyfin deletes an item's containing folder, recursively - not just the media file:

• Video.GetDeletePaths() returns ContainingFolderPath with IsDirectory = true whenever the item is not in a mixed folder.
• LibraryManager.DeleteItemPath then calls Directory.Delete(fullName, true).

Observed live on Jellyfin 10.11.11 and Emby 4.9.x by pointing both at a read-only library, so the delete fails and reports the path it tried to remove:

[ERR] Error processing request: Access to the path '/media/movies/Elephant Dream (2006)' is denied. URL DELETE /Items/c9672c6e7201580958b3429f72c70d4b.

That is the folder, not the file. In a mixed-folder library both delete only the file, which is also correct - the folder still holds the other movies.

So on this path there is nothing stranded, and deriving fences from the media server (option 1) would clean folders the server has already removed. Option 1 is therefore not worth building on the evidence available.

Plex is the open question: its delete returned HTTP 400 in the dev stack despite allowMediaDeletion=true, so I could not exercise it and make no claim about what it leaves behind. If someone can show a Plex delete stranding sidecars, that is a separate, much narrower issue than this one.

[maintainerr-automation]

🎉 This issue has been resolved in version 3.21.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀