Summary
Both issues come from how qualityProfileId is handled on the library edit paths, so I think they fit in one small change. I compared against #760's file list and, as far as I can tell, it only validates the add and monitoring paths, so the two do not overlap: none of the files this touches appear in it.
- #1056:
PUT /library/{id}withqualityProfileId: -1("use default") and no default profile configured set the book's profile to null. That discarded the existing assignment and, I think, dropped the book out of auto-search. - #1057: single update and bulk edit stored any requested id without checking that the profile exists. Bulk edit also did not handle the
-1sentinel at all, so it stored-1literally. The issue did not mention that part, I found it while reading the bulk path.
Changes
Added
LibraryQualityProfileSelection.ResolveAsync, one helper that turns a requested id into an existing profile id (resolving-1to the default) or throwsApplicationValidationException.
Fixed
- Single update resolves the profile before any other change is applied, and returns the existing 400 mapping (
ToApplicationExceptionResult) if it cannot. A rejected request leaves the current assignment alone. It also runs before the deprecated BasePath rewrite, so I think a bad profile id should not leave a half-applied update behind. - Bulk edit resolves
-1to the default profile id and checks existence, and reports a rejection in that item'serrorslist like its other per-item failures. ApplyQualityProfileAsyncis removed; the helper replaces its lookup andApplyMetadataUpdatesAsyncjust assigns the resolved id.
Testing
Seven new tests in LibraryController_QualityProfileSelectionTests (corpus book A Princess of Mars), driven through UpdateAudiobook and BulkUpdateAudiobooks with the real repositories.
Control, same test file on unmodified canary b734292: 5 of 7 fail...
Automated Canary build