From d7727224c2f5024c9981bc70a274826beb7f1cdf Mon Sep 17 00:00:00 2001 From: zerafachris Date: Fri, 17 Jul 2026 16:44:25 +0200 Subject: Skip corrupt KeyframeData rows during full system backup A single row with malformed KeyframeTicks JSON (e.g. a truncated array from an interrupted write) currently aborts the entire backup, because the try/catch in BackupService.CreateBackupAsync only wraps serialization of an already-materialized entity, not the enumeration itself. EF Core throws JsonReaderException from MoveNextAsync() while materializing the corrupt row, which propagates past that catch block. Switch to manual enumerator iteration so MoveNextAsync() failures can be caught per-row, logged as a warning identifying the affected table, and skipped, allowing the remaining rows and the rest of the backup to complete. Fixes #17216 Co-Authored-By: Claude Sonnet 5 --- .../FullSystemBackup/BackupService.cs | 44 +++++++++++++++++----- 1 file changed, 34 insertions(+), 10 deletions(-) (limited to 'Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs') diff --git a/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs b/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs index a534fa5fa0..16daba0991 100644 --- a/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs +++ b/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs @@ -359,18 +359,42 @@ public class BackupService : IBackupService jsonSerializer.WriteStartArray(); var set = entityType.ValueFactory().ConfigureAwait(false); - await foreach (var item in set.ConfigureAwait(false)) + var enumerator = set.GetAsyncEnumerator(); + await using (enumerator) { - entities++; - try + while (true) { - using var document = JsonSerializer.SerializeToDocument(item, _serializerSettings); - document.WriteTo(jsonSerializer); - } - catch (Exception ex) - { - _logger.LogError(ex, "Could not load entity {Entity}", item); - throw; + // Reading the next row can itself throw, e.g. when a column contains malformed + // JSON (see https://github.com/jellyfin/jellyfin/issues/17216). Catch that here so a single + // corrupt row is skipped, logged for manual follow-up, and does not abort the whole backup. + bool hasNext; + try + { + hasNext = await enumerator.MoveNextAsync(); + } + catch (Exception ex) + { + _logger.LogWarning(ex, "Could not read next entity of type {Table}, the underlying data appears to be corrupt. Skipping this row and continuing backup; the affected database row should be inspected and fixed manually", entityType.SourceName); + continue; + } + + if (!hasNext) + { + break; + } + + var item = enumerator.Current; + entities++; + try + { + using var document = JsonSerializer.SerializeToDocument(item, _serializerSettings); + document.WriteTo(jsonSerializer); + } + catch (Exception ex) + { + _logger.LogError(ex, "Could not load entity {Entity}", item); + throw; + } } } -- cgit v1.2.3 From 663a873e07b436cd99fa7b00efa2bcd68e11fb23 Mon Sep 17 00:00:00 2001 From: zerafachris Date: Sat, 18 Jul 2026 16:47:23 +0200 Subject: fix: log corrupt KeyframeData row read failures as errors, not warnings Per review feedback from cvium: failing to read/backup an entity due to corrupt underlying data is a significant event that should be surfaced as an error, not silently downgraded to a warning. --- Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs') diff --git a/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs b/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs index 16daba0991..765f8bfb73 100644 --- a/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs +++ b/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs @@ -374,7 +374,7 @@ public class BackupService : IBackupService } catch (Exception ex) { - _logger.LogWarning(ex, "Could not read next entity of type {Table}, the underlying data appears to be corrupt. Skipping this row and continuing backup; the affected database row should be inspected and fixed manually", entityType.SourceName); + _logger.LogError(ex, "Could not read next entity of type {Table}, the underlying data appears to be corrupt. Skipping this row and continuing backup; the affected database row should be inspected and fixed manually", entityType.SourceName); continue; } -- cgit v1.2.3 From 0d629591ed8b491e6e3560f72b12d737e4f3922f Mon Sep 17 00:00:00 2001 From: Cody Robibero Date: Mon, 20 Jul 2026 20:15:05 -0400 Subject: Remove comments about JSON error handling Removed comments explaining error handling for malformed JSON during backup. --- Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs | 3 --- 1 file changed, 3 deletions(-) (limited to 'Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs') diff --git a/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs b/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs index 765f8bfb73..7c10a5dc77 100644 --- a/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs +++ b/Jellyfin.Server.Implementations/FullSystemBackup/BackupService.cs @@ -364,9 +364,6 @@ public class BackupService : IBackupService { while (true) { - // Reading the next row can itself throw, e.g. when a column contains malformed - // JSON (see https://github.com/jellyfin/jellyfin/issues/17216). Catch that here so a single - // corrupt row is skipped, logged for manual follow-up, and does not abort the whole backup. bool hasNext; try { -- cgit v1.2.3