fix: clean NaN values from entities before database save to prevent TypeORM errors - #1166
Open
Tianpapa wants to merge 2 commits into
Open
fix: clean NaN values from entities before database save to prevent TypeORM errors#1166Tianpapa wants to merge 2 commits into
Tianpapa wants to merge 2 commits into
Conversation
When selecting a thumbnail or preview size, findClosestinSorted picks the numerically closest value. For grid thumbnails this works fine, but for lightbox full-screen preview the expected behavior is ceiling: pick the next available size that is >= the display viewport. The issue manifests on high-DPI devices: e.g. a 3200x2136px phone with DPR=2 has a CSS viewport of ~1600px. With sizes [320, 1200, 2136, 2160], the algorithm picks 1200px (|1600-1200|=400) instead of 2136px (|1600-2136|=536), because closest-match favors the smaller size. Added Utils.findCeilinginSorted() and used it in MediaIcon.getMediaSize() for thumbnail/preview size selection. findClosestinSorted is kept for backward compatibility.
Tianpapa
force-pushed
the
fix/clean-nan-before-db-save
branch
2 times, most recently
from
June 19, 2026 08:35
8884fb3 to
57521b2
Compare
EXIF metadata parsing can produce NaN values (e.g., from malformed GPS coordinates or empty numeric fields). When these NaN values reach the database layer, TypeORM fails to save entities because SQLite does not support NaN. This fix: 1. Adds Utils.cleanNaN() - a recursive deep-clean function that replaces NaN (both number and string "NaN") with null 2. Calls it in IndexingManager.saveChunk() before saving entities The cleanup is done at the lowest common point (database save) to catch NaN from any source without modifying every metadata parser.
Tianpapa
force-pushed
the
fix/clean-nan-before-db-save
branch
from
June 19, 2026 08:43
57521b2 to
19d28d8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When EXIF metadata contains malformed GPS coordinates or other empty numeric fields, the metadata parser can produce
NaNvalues in the entity objects. When these entities are saved to the database via TypeORM, the write fails because SQLite does not support NaN values.This prevents photos with problematic EXIF data from being indexed, and the indexing job gets stuck retrying failed saves.
Changes
Utils.cleanNaN()— a recursive deep-clean function that traverses an object tree and replacesNaN(both JavaScript'snumberNaN and the string"NaN") withnull.IndexingManager.saveChunk()— entities are cleaned before being passed torepository.save(), catching NaN from any upstream source.Design decisions
numberNaN and string"NaN"are caught, as EXIF libraries may produce either type.