Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Drive API] Error 400 when replacing existing file during upload since v3.5.0 #635

Open
tobihagemann opened this issue Mar 12, 2024 · 1 comment

Comments

@tobihagemann
Copy link

After updating our dependencies, we noticed that something has changed between v3.4.0 and v3.5.0 that I can't quite explain. One of our integration tests for replacing an existing file fails with an unexpected HTTP 400 response and the following content:

Can not finalize upload. Current size is 19. Expected final size is 13.

I've tried to analyze the diff between v3.4.0 and v3.5.0, but couldn't find anything that made sense to me. I believe bfe8cd0 is the most relevant commit, but I'm having trouble understanding the changes and how this is relevant to our error.

In a nutshell, we're using GTLRDriveQuery_FilesUpdate.query() to build our query for replacing an existing file and then using driveService.executeQuery() to execute it.

Any ideas what I should be looking for? I'm just a bit puzzled by this because I'm getting a "Bad Request" error from the server just by updating the dependency, which tells me that the client doesn't send the same request as before the update. (So yes, v3.4.0 still works fine in our case.)

tobihagemann added a commit to cryptomator/cloud-access-swift that referenced this issue Mar 12, 2024
@thomasvl
Copy link
Member

So the change you reference moved a user agent calculation off to a worker queue allowing query starting to not block for as long. I.e. - there's a timing change on how fast the start returns vs. when the networking might actually start.

Given the quoted error you are seeing, my guess if you've got a race that you've always had and the timing change just exposed it. The file you are trying to upload was changed between the start call and the completion of the whole upload request, and the update code paths not catch that where as before they didn't.

Generally speaking, you don't want to be mutating a file while you are trying to upload it as then you don't really know what state is getting sent to the server (we don't/can't assume there is space to buffer the file any place). If you are trying to upload a log file or something that you do want to change with time, you'll need to do the buffering your self – i.e. - roll to a new file at the start of each upload and delete the old after completion, or maybe copy the file each time you start an upload, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants