You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
As reported by @corps:
My hypothesis is that because the
directory.uploads
state value uses thefileKey
to determine uniqueness -- justprojectName:fileName
, combined with the fact that inupload_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 wrongnext_blob_hash
.The text was updated successfully, but these errors were encountered: