fix(dav): keep upload session while its chunks are being assembled - #63122
Open
solracsf wants to merge 1 commit into
Open
fix(dav): keep upload session while its chunks are being assembled#63122solracsf wants to merge 1 commit into
solracsf wants to merge 1 commit into
Conversation
…ng assembled The final MOVE of a chunked upload streams the chunks into the destination one after another, opening each only when it gets there. A client that gives up on the upload - the desktop client does this when the assembly MOVE answers with an ambiguous 502 - deletes the upload session, which pulls the remaining chunks out from under the assembly that is still reading them. The assembly then fails on a chunk that no longer exists, and the upload has to be retried from the start. Hold an exclusive lock for the duration of the assembly and take the same lock before deleting a session, so a delete that arrives mid-assembly is answered with 423 instead of destroying the chunks. The lock sits on a path with nothing behind it, the way createFile() guards its part file, so it does not collide with the deletion of the session that ends a successful move. The lock is held through the file locking provider rather than a distributed cache, so it also works on instances that have no memcache configured. Two paths remain outside it by design: the background upload cleanup job deletes sessions through the filesystem API, but only ever expires sessions whose files are all older than the TTL, and the lock itself expires with the locking provider's TTL, which bounds how long a crashed assembly keeps its session undeletable. Signed-off-by: Git'Fellow <12234510+solracsf@users.noreply.github.com>
solracsf
requested review from
Altahrim and
salmart-dev
and removed request for
a team
August 10, 2026 12:44
Merged
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.
Summary
The final MOVE of a chunked upload streams the chunks into the destination one after another, opening each only when it gets there. A client that gives up on the upload - the desktop client does this when the assembly MOVE answers with an ambiguous 502 - deletes the upload session, which pulls the remaining chunks out from under the assembly that is still reading them. The assembly then fails on a chunk that no longer exists, and the upload has to be retried from the start.
This PR holds an exclusive lock for the duration of the assembly and take the same lock before deleting a session, so a delete that arrives mid-assembly is answered with 423 instead of destroying the chunks. The lock sits on a path with nothing behind it, the way
createFile()guards its part file, so it does not collide with the deletion of the session that ends a successful move.The lock is held through the file locking provider rather than a distributed cache, so it also works on instances that have no memcache configured. Two paths remain outside it by design: the background upload cleanup job deletes sessions through the filesystem API, but only ever expires sessions whose files are all older than the TTL, and the lock itself expires with the locking provider's TTL, which bounds how long a crashed assembly keeps its session undeletable.
Checklist
3. to review, feature component)stable32)AI (if applicable)