-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
As reported by @corps:
So, I noticed that if a user starts a download but doesn't complete it, then tries to upload a different file to the same path, the uploading fails because it re-uses the existing Upload model, which may have a next_blob_hash that doesn't match the new file that is replacing it.
Should we change this behavior to more of a create_or_reset_upload? If the upload does exist, update its file_by_position and next_blob* params to defaults.
My hypothesis is that because the directory.uploads state value uses the fileKey to determine uniqueness -- just projectName:fileName, combined with the fact that in upload_actions, cancelUpload only removes uploads that have completed (not cancelled or just paused), the client-side uploader tries to continue an existing upload when the user switches files instead of clearing out the upload and starting over. So it sends the wrong next_blob_hash.
Metadata
Metadata
Assignees
Labels
No labels