Conversation
Cherry-picked from upstream immich-31585 ahead of the v3.3.0 rebase. The new base image ships Node 24.21.0 instead of 24.18.1. Node 24.16 through 24.19 never release a Blob after fetch streams it as a request body, and every machine learning request sends the preview image as a Blob in FormData. The server therefore kept one preview in memory per ML request until restart, about 0.35 MiB per job on a large pet detection reset. Node 24.20.0 fixed this.
Deeds67
pushed a commit
that referenced
this pull request
Sep 28, 2026
Backport of upstream immich-31854, shipped in Immich v3.2.4. Supersedes #1146: the new base image also ships a Node release past the 24.16-24.19 Blob stream leak (#1144). (cherry picked from commit 6786b82) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Daniel Dietzler <mail@ddietzler.dev>
Deeds67
added a commit
that referenced
this pull request
Sep 28, 2026
* fix(mobile): sync status page goes blank when the counts query fails Backport of upstream immich-31644 (cherry-pick of immich-31642), shipped in Immich v3.2.3. (cherry picked from commit 91d34f9) Co-authored-by: Santo Shakil <santoshakil@users.noreply.github.com> * chore(deps): update base-image to v202609281550 Backport of upstream immich-31854, shipped in Immich v3.2.4. Supersedes #1146: the new base image also ships a Node release past the 24.16-24.19 Blob stream leak (#1144). (cherry picked from commit 6786b82) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Daniel Dietzler <mail@ddietzler.dev> * chore: record Immich v3.2.4 as the upstream base With the two v3.2.3/v3.2.4 changes backported, main now contains everything in upstream v3.2.4. Neither release touches server/src/schema/, so the revert-to-immich script and the migration coverage are unchanged. --------- Co-authored-by: immich-push-o-matic[bot] <179150890+immich-push-o-matic[bot]@users.noreply.github.com> Co-authored-by: Santo Shakil <santoshakil@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Daniel Dietzler <mail@ddietzler.dev>
Collaborator
Author
|
Merged in #1151 |
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.
Fixes #1144.
Problem
The server's jobs process grows by roughly 0.35 MiB per machine learning job and never releases it. On a large pet detection reset this reaches tens of GiB (the reporter saw ~0.4 GiB per 1,000 jobs; only a restart frees it).
Cause
Node 24.16 through 24.19 never release a
Bloboncefetchhas streamed it as a request body.MachineLearningRepository.getFormData()sends every/predictrequest asFormDatawith the preview image in aBlob, so each ML request (face detection, smart search, OCR, pets) keeps one preview in memory. Our current base image,202608300913, ships Node 24.18.1. Node 24.20.0 fixed the bug.Evidence:
Node / BackingStoreobjects (1.16 GiB), each owned by aBlobheld by a native global handle, surviving a forced GC.for await (const _ of blob.stream());on 400 KB blobs, 2,000 iterations: 24.15.0 → 25 MiB, 24.18.1 → 763 MiB, 24.19.0 → 812 MiB, 24.20.0 → 21 MiB, 24.21.0 → 9 MiB.Fix
Cherry-pick upstream's base-image bump (immich-31585, already on the rolling v3.3.0 branch) to
mainahead of the rebase.base-server-prod:202609151314ships Node 24.21.0. The server code is unchanged.Validation
On a clone of the personal instance running this branch's RC image (
fix-base-image-node-blob-leak-rc1, Node 24.21.0):arrayBuffers6 → 7 MiB after forced GC. On v5.7.0 the same test gave 10 → 1,169 MiB for 3,184 jobs.Not covered by the clone (read-only S3): thumbnail generation and video transcoding under the new libvips/ffmpeg in the base image. Those rely on this PR's e2e CI.