immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

[PR #16847] Feat/chunked backup #15071

New Issue
Closed
opened 2026-02-05 15:42:53 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-05 15:42:53 +03:00
Owner
Copy Link

Original Pull Request: https://github.com/immich-app/immich/pull/16847

State: closed
Merged: No

Description

This PR is a draft implementation of a chunked upload feature requested in #1674
It solves the 100MB upload limit enforced by CloudFlare tunnels.
It also allows interrupted uploads to resume from the last 10MB mark.

How Has This Been Tested?

I have a single cloudflared + immich docker-compose project which runs behind NAT.
I'm able to backup large (up to 1GB) videos from my phone through a CF tunnel with no problem.

How it works

Mobile client does the following for each backed up asset:

  • calculate the SHA1 checksum of an asset
  • using SHA1 as a key, request a list of chunks already present on the server
  • upload missing chunks while checking that the size of existing chunks match the expectation
  • promote a complete list of uploaded chunks to a library asset

What's missing

  • some parameters validation may be missing, potentially creating a security vulnerability where (authenticated) attacker can create files in random places
  • refactor the service-side code (create a new service, extend existing enums/repositories/etc)
  • need to create a new type of scheduled cleanup job which will remove chunks from failed backup attempts (i.e. backup never had a chance to finish before the asset was permanently removed from the phone)
  • implement the same logic in web and cli clients
  • remove cli part sub-command which was added for testing

API Changes

There is a new API AssetParts controller added with the following methods:

  • GET /api/asset-parts/:sha1 - given a (future) asset checksum, return a list of already uploaded chunks (with sizes)
  • PUT /api/asset-parts/:sha1/:partNo - upload a chunk
  • POST /api/asset-parts/:sha1 - combine all loaded chunks into a singe asset file and add it to the library

Checklist:

This is a very quick and dirty hack to fix a problem which prevents me personally from using immich.
It is by no means ready to be merged. While I'm planning to tidy it up eventually, I'm not sure when I will
be able to get back to it. I would appreciate if someone with more flutter/typescript/etc experience could help me with this.
Or just fork this branch & raise a new PR.

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation if applicable
  • I have no unrelated changes in the PR.
  • I have confirmed that any new dependencies are strictly necessary.
  • I have written tests for new code (if applicable)
  • I have followed naming conventions/patterns in the surrounding code
  • All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
  • All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)
**Original Pull Request:** https://github.com/immich-app/immich/pull/16847 **State:** closed **Merged:** No --- ## Description This PR is a draft implementation of a chunked upload feature requested in #1674 It solves the 100MB upload limit enforced by CloudFlare tunnels. It also allows interrupted uploads to resume from the last 10MB mark. ## How Has This Been Tested? I have a single cloudflared + immich docker-compose project which runs behind NAT. I'm able to backup large (up to 1GB) videos from my phone through a CF tunnel with no problem. ## How it works Mobile client does the following for each backed up asset: - calculate the SHA1 checksum of an asset - using SHA1 as a key, request a list of chunks already present on the server - upload missing chunks while checking that the size of existing chunks match the expectation - promote a complete list of uploaded chunks to a library asset ## What's missing - [ ] some parameters validation may be missing, potentially creating a security vulnerability where (authenticated) attacker can create files in random places - [ ] refactor the service-side code (create a new service, extend existing enums/repositories/etc) - [ ] need to create a new type of scheduled cleanup job which will remove chunks from failed backup attempts (i.e. backup never had a chance to finish before the asset was permanently removed from the phone) - [ ] implement the same logic in `web` and `cli` clients - [ ] remove cli `part` sub-command which was added for testing ## API Changes There is a new API `AssetParts` controller added with the following methods: - `GET /api/asset-parts/:sha1` - given a (future) asset checksum, return a list of already uploaded chunks (with sizes) - `PUT /api/asset-parts/:sha1/:partNo` - upload a chunk - `POST /api/asset-parts/:sha1` - combine all loaded chunks into a singe asset file and add it to the library ## Checklist: This is a very quick and dirty hack to fix a problem which prevents me personally from using immich. It is by no means ready to be merged. While I'm planning to tidy it up eventually, I'm not sure when I will be able to get back to it. I would appreciate if someone with more flutter/typescript/etc experience could help me with this. Or just fork this branch & raise a new PR. - [ ] I have performed a self-review of my own code - [ ] I have made corresponding changes to the documentation if applicable - [ ] I have no unrelated changes in the PR. - [ ] I have confirmed that any new dependencies are strictly necessary. - [ ] I have written tests for new code (if applicable) - [ ] I have followed naming conventions/patterns in the surrounding code - [ ] All code in `src/services/` uses repositories implementations for database calls, filesystem operations, etc. - [ ] All code in `src/repositories/` is pretty basic/simple and does not have any immich specific logic (that belongs in `src/services/`)
OVERLORD added the pull-request label 2026-02-05 15:42:53 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#15071
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?