I’m troubleshooting an issue where every time my file upload resumes (from an Android client to tusd to Google Cloud Storage), the offset comes back as 0 and my upload starts from the beginning. Looking at non-GCS code (like the s3store), I see partial files being written (putIncompletePartForUpload). I don’t see similar logic in gcsstore. It looks like offset is determined by an .info file that lives in the GCS bucket, but that file seems to have offset = 0 until the full upload completes. Does this mean partial files aren’t saved in the GCS backend?
That’s weird. Can you reproduce this using curl commands or similar to make sure this is not a problem with the Android library?
The putIncompletePartForUpload method is S3-specific because S3 does not always allow storing chunks smaller than 5MB. Since GCS does not have such an artificial limit, gcsstore does not need such a method.
That’s not correct. The offset is determined by enumerating all uploaded chunks and summing their sizes. The offset in the .info file is ignored while the upload is not completed. See https://github.com/tus/tusd/blob/master/pkg/gcsstore/gcsstore.go#L177-L227
No, partial uploads should be saved by tusd. Otherwise resumable uploads would not make a lot of sense 
Hi marius,
I’m working with tjlahr on this issue. After digging more into it, it looks like there are a couple of things happening. Here is more context. We are using the java (and android) clients to upload images to the tusd server. In the java client, we are setting the chunk size to 1KB. It looks like the TusUploader.java class sets connection.setChunkedStreamingMode(0); so that it streams all of the chunks of the image upload inside of the same http request body. This shows up in the tusd server as only receiving one PATCH request from the client when the upload begins.
On the tusd side, it seems that in the unrouted_handler writeChunk function there is an area where the max size is set of how much data to read from the incoming PATCH requests body until it stops to go write it. https://github.com/tus/tusd/blob/master/pkg/handler/unrouted_handler.go#L592-L616 From what we have observed so far in our use case, tusd is always setting that max size to be the size of the entire image that we are uploading (typically between 10KB-100KB). Therefore it seems to only ever be trying to write one chunk to GCS.
The problem occurs when we simulate a failed connection mid-upload in the android client. When we shut the clients internet off, our assumption is that tusd would write whatever it had received so far (even if it was less than the max size it was expecting), and then when our client reconnects the server would respond with the Tus-Offset of wherever the upload was cut off last time. However what we have seen instead is that the server never writes that one chunk to GCS and we only see a .info file in GCS, and when the client reconnects it always gets a response back off offset = 0, so the upload starts over at 0 again.
I hope this details the problem more fully. It is hard for me to infer whether we are missing a configuration setting in either the Android client, the Tusd server, or if this is actually an issue. Let me know if I can provide more detail.
Yes, you are correct that this is what should happen.
Your description helps a lot. Could you also paste the corresponding tusd logs in here? I have an idea that there might be some info in there