File appears in Addons/File Storage. Clicking on the filename returns a 404.



Attempting to get the file via the GCS url returns the following:



NoSuchKey

The specified key does not exist.





This is happening quite a fair bit recently.

Hey I'm going to need some more information--



You are uploading a file through the Android library, yeah? How large is the file? Can you also confirm that your `UploadProgressListenener` is firing the onSuccess callback?



If you take a look at our troubleshooting guide (http://devcenter.kinvey.com/android/guides/troubleshooting), you can turn on explicit request logging which might give us a more detailed error message.

> You are uploading a file through the Android library, yeah?



Yes. Uploading via Android library. E.g.

kinveyClient.linkedData("photo", Photo.class).saveBlocking(entity, null).execute();



> How large is the file?



https://dl.dropboxusercontent.com/u/275485/Screen%20Shot%202013-12-13%20at%2012.42.27%20PM.png



> Can you also confirm that your UploadProgressListenener is firing the onSuccess callback?



Added a UploaderProgressListener to the code above. It is not firing onSuccess even when the photo is successfully uploaded.

So file operations are actually two step-- first, metadata about the file is saved in your backend (that's the FileMetaData object), and then second, the file is streamed from Google Cloud Storage (where the file is actually stored). It looks like the first step is completing successfully, which is why you are seeing the data in the console-- but the second step, uploading to GCS is failing.



Unfortunately there isn't much that can be done about this, and the files will need to be uploaded again. There are a ton of reasons that an issue might occur during upload, and I would recommend requiring wifi or ensuring there is a good connection during the upload progress. It might also be a good idea to add retry logic, so that if onFailure is called the user will be alerted and can attempt to upload again.



Also, you mentioned that onSuccess isn't being called? That doesn't sound right-- I just did a quick test, and I am seeing the onSuccess callback. Can you take another look at that and ensure the upload is completing successfully without the callback? Also, try adding these logging statements to your UploadProgressListener, which might give more information:



...

@Override

public void progressChanged(MediaHttpUploader uploader) throws IOException {

Log.i("TAG", "upload progress: " + uploader.getUploadState());

}

...

KinveyClientCallback's onSuccess is called.



MediaHttpUploader's onSuccess is not called.



MediaHttpUploader's progressChanged:

upload progress: UPLOAD_IN_PROGRESS

upload progress: INITIATION_STARTED

upload progress: INITIATION_COMPLETE

upload progress: UPLOAD_COMPLETE

Hi guys, any updates on this?



Thanks in advance!

Hey sorry for the delay in getting back to you, I was out of town for the holidays.



I took another look at the code and noticed that there is a bug in the onSuccess callback for the media uploader, depending on the order it can not be called. I have gotten the fix in and will get a release out with it later this week-- Still, this won't actually help with the problem but it will help with troubleshooting.



Can you also keep an eye on the onFailure method of the `UploadProgressListener`? If I turn on airplane mode in the middle of an upload I am getting that called, which your app might be able to use to indicate a failure. Is it possible to recommend a user re-perform their action after an upload has failed?

Turning on airplane mode in the middle of an upload:

KinveyClientCallback onFailure called.



UploaderProgressListener onFailure is not called.



Logs:

UploaderProgressListener.progressChanged -> UPLOAD_IN_PROGRESS

UploaderProgressListener.progressChanged -> INITIATION_STARTED

KinveyClientCallback.onFailure -> Unable to resolve host "baas.kinvey.com": No address associated with hostname

By the way, the code is being run from within a IntentService.

Hey,



So the callbacks not firing is a bug with the linked data API-- note that this does not occur when using the file api directly.



As a workaround, can you try pulling the id field out of the entity and using the file api directly?



I am planning on revisiting linked data in the near future to add support for separating the file download from the entity retrieval, which will make things like lazy-loading possible.