`/library/preview-path` returns an absolute `relativePath`, silently disabling "Add to Library" in the Add Book modal

[emguide]

Environment

• Listenarr canary tag, version shown in UI: 1.3.0
• Image digest: sha256:734941169e4ebb5b9fd1ee5e6d99d904cd687eaa79803535c00c7d0302703430 (pulled 2026-08-14, confirmed latest canary at that time)
• Docker Compose deployment, bridge networking

Bug

Opening the "Add to Library" modal for any new (not-yet-added) search result leaves the Add to Library button permanently greyed out, with no visible error explaining why.

Root cause

When the modal opens, the frontend calls POST /api/v1/library/preview-path to pre-fill the destination path. Example request/response against a clean root folder (/audiobooks/Audiobooks, isDefault: true):

POST /api/v1/library/preview-path
{"metadata": {...}, "destinationRoot": "/audiobooks/Audiobooks"}

200 OK
{
  "fullPath": "/audiobooks/Audiobooks/Ray Nayler/The Mountain in the Sea",
  "relativePath": "/audiobooks/Audiobooks/Ray Nayler/The Mountain in the Sea",
  "root": "/audiobooks/Audiobooks"
}

relativePath is identical to fullPath and it's an absolute path, not relative to root. It should be Ray Nayler/The Mountain in the Sea.

The frontend (AddLibraryModal) takes this value at face value and populates the relative-path input with it. Its own client-side validation then correctly notices the value starts with / and treats it as invalid:

"Enter a path relative to the selected configured root folder."

That validation error is never surfaced visibly in the modal body it just silently disables the submit button via the button's disabled binding (T.value || Y.value || !!q.value). This also causes the "Effective destination" preview text to double the root prefix: /audiobooks/Audiobooks/audiobooks/Audiobooks/Ray Nayler/The Mountain in the Sea.

Net effect: every attempt to add a new audiobook through search results is silently blocked, with no error message pointing at the cause.

Steps to reproduce

1. Add New and search for any book not already in your library (e.g. by ASIN).
2. Click the result's Add button to open the "Add to Library" modal.
3. Observe the "Add to Library" button is disabled/greyed out with no visible reason.
4. Inspect the "relative path" field and it contains an absolute path starting with /.

Expected behavior

/library/preview-path should return relativePath relative to destinationRoot, and/or the modal should surface the validation error text next to the field instead of just disabling the button silently.

Workaround

Manually edit the relative-path field in the modal to strip the leading root-folder path (e.g. change /audiobooks/Audiobooks/Author/Title to Author/Title). The validation error clears and the Add button becomes clickable.

[m4bard]

I think this is the same defect as #820, and I have put the fuller analysis there to keep it in one place.

The short version. LibraryPreviewPathWorkflow.cs:46 seeds var relativePath = fullPath, and the correction at :69 only runs when the semantics resolution comes back Valid. Line 61 calls ResolveAsync(semanticsRoot) with no mode, so it defaults to Auto and depends on an FS_IOC_GETFLAGS ioctl that fails on CIFS, NFS, vfat, exFAT and most FUSE mounts. When it fails, the endpoint returns the absolute path in relativePath and a 200.

#820 is the same resolution failing in ManualImportDestinationTracker.cs:66, which throws instead of degrading. Same cause, opposite handling.

Two details specific to this issue that may save you some time.

Pre-#717 this was a plain string slice with no probe, so it could not fail:

// 4555ad21
var relativePath = fullPath;
if (!string.IsNullOrEmpty(root) &&
    fullPath.StartsWith(root, StringComparison.OrdinalIgnoreCase))
{
    relativePath = fullPath[root.Length..].TrimStart(...);
}

And the client has a fallback that would have rescued this, but it is defeated by the value being non-empty. deriveRelative in AddLibraryModal.vue returns the server value immediately if it is a non-empty string, so it never reaches its own slicing logic. Had the server returned an empty string on failure rather than the absolute path, I think the modal would have corrected itself and nobody would have noticed. That is why returning "" on failure is a one-line option worth considering alongside the larger fix, though it does leave the server quietly relying on one particular client to be correct.

One correction to the report, offered gently since it changes what to look for. The validation error is rendered, unconditionally, in AddLibraryModal.vue around :401. What is missing is its CSS: the class path-validation-error is used there but never defined in that component's scoped style block, while EditAudiobookModal.vue defines both it and the warning class. So the text is present but unstyled, sitting next to a styled warning. That reads as "no error shown" without being it, and it is a different fix from the path bug.