[PR #15956] [MERGED] fix: Handle unknown item types gracefully in DeserializeBaseItem #14477

New Issue

OVERLORD · 2026-02-07T07:30:27+03:00

OVERLORD commented

2026-02-07 07:30:27 +03:00

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/15956
Author: @ZeusCraft10
Created: 1/6/2026
Status: ✅ Merged
Merged: 1/9/2026
Merged by: @Bond-009

Base: master ← Head: fix/issue-15945-unknown-type-deserialization

📝 Commits (1)

0ff869d fix: Handle unknown item types gracefully in DeserializeBaseItem

📊 Changes

3 files changed (+100 additions, -19 deletions)

View changed files

📝 Jellyfin.Server.Implementations/Item/BaseItemRepository.cs (+23 -17)
📝 Jellyfin.Server/Migrations/Routines/MigrateLibraryDb.cs (+5 -2)
➕ tests/Jellyfin.Server.Implementations.Tests/Item/BaseItemRepositoryTests.cs (+72 -0)

📄 Description

The Problem

I reproduced issue #15945 where querying /Items\ with
ecursive=true\ and \isLocked=false\ throws a 500 error. After digging into it, I found that the root cause is in \DeserializeBaseItem\ - when an item has a type that can't be resolved (like from a plugin that was removed), it throws an \InvalidOperationException\ instead of handling it gracefully.

What I Changed

The fix is pretty straightforward - instead of throwing when we encounter an unknown type, we now:

Log a warning with the item ID and type name (so admins know what's happening)
Return
ull\ instead of crashing
Filter out the null results in all the calling code

This follows the same pattern that's already used for JSON deserialization errors a few lines down - log and continue rather than blow up the whole request.

Changes

**\BaseItemRepository.cs**: Updated \DeserializeBaseItem\ to return nullable and handle unknown types with a warning log. Updated all 8 call sites to filter out nulls.
**\MigrateLibraryDb.cs**: Added null check since this migration also uses \DeserializeBaseItem\
Added tests: Created \BaseItemRepositoryTests.cs\ with tests to verify the new behavior

Testing

All new tests pass
Verified the existing test suite still passes
The fix ensures that items with unknown types are simply skipped instead of causing a server error

Fixes #15945

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/15956 **Author:** [@ZeusCraft10](https://github.com/ZeusCraft10) **Created:** 1/6/2026 **Status:** ✅ Merged **Merged:** 1/9/2026 **Merged by:** [@Bond-009](https://github.com/Bond-009) **Base:** `master` ← **Head:** `fix/issue-15945-unknown-type-deserialization` --- ### 📝 Commits (1) - [`0ff869d`](https://github.com/jellyfin/jellyfin/commit/0ff869dfcd4ab527dccc975c9be414d1c050a90d) fix: Handle unknown item types gracefully in DeserializeBaseItem ### 📊 Changes **3 files changed** (+100 additions, -19 deletions) <details> <summary>View changed files</summary> 📝 `Jellyfin.Server.Implementations/Item/BaseItemRepository.cs` (+23 -17) 📝 `Jellyfin.Server/Migrations/Routines/MigrateLibraryDb.cs` (+5 -2) ➕ `tests/Jellyfin.Server.Implementations.Tests/Item/BaseItemRepositoryTests.cs` (+72 -0) </details> ### 📄 Description ## The Problem I reproduced issue #15945 where querying \/Items\ with \ ecursive=true\ and \isLocked=false\ throws a 500 error. After digging into it, I found that the root cause is in \DeserializeBaseItem\ - when an item has a type that can't be resolved (like from a plugin that was removed), it throws an \InvalidOperationException\ instead of handling it gracefully. ## What I Changed The fix is pretty straightforward - instead of throwing when we encounter an unknown type, we now: 1. Log a warning with the item ID and type name (so admins know what's happening) 2. Return \ ull\ instead of crashing 3. Filter out the null results in all the calling code This follows the same pattern that's already used for JSON deserialization errors a few lines down - log and continue rather than blow up the whole request. ## Changes - **\BaseItemRepository.cs\**: Updated \DeserializeBaseItem\ to return nullable and handle unknown types with a warning log. Updated all 8 call sites to filter out nulls. - **\MigrateLibraryDb.cs\**: Added null check since this migration also uses \DeserializeBaseItem\ - **Added tests**: Created \BaseItemRepositoryTests.cs\ with tests to verify the new behavior ## Testing - All new tests pass - Verified the existing test suite still passes - The fix ensures that items with unknown types are simply skipped instead of causing a server error Fixes #15945 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

OVERLORD added the pull-request label 2026-02-07 07:30:27 +03:00

OVERLORD closed this issue

2026-02-07 07:30:29 +03:00

Sign in to join this conversation.

Branches Tags

master

renovate/major-skiasharp-monorepo

renovate/sharpcompress-0.x

renovate/svg.skia-5.x

renovate/ghcr.io-devcontainers-features-docker-in-docker-4.x

release-10.11.z

standards-fix

release-10.9.z

openapi-cache

release-10.10.z

explicit-load

explicit-load-v2

feature/entity-framework

only-count-folder-item

fix/ci-workflow-refactor

release-10.8.z

release-10.7.z

EraYaN-add-management-interface

release-10.6.z

release-10.5.z

release-10.4.z

release-10.3.z

release-10.2.z

release-10.1.0

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#14477