Third Light Developer Exchange

mdyason

Member

Registered: 2015-01-20

Posts: 43

Confirmation of upload succeed or fail.

On uploading files we have been doing the following:
1. Call Upload.CreateUpload and pass in the containerID as destination and synchronous as true.  This returns Uploadkey.
2. Call upload.AddFilesToUpload and pass in the uploadkey and filedata.  This returns:
        "outParams": {"succeeded": {"file1": "32039094896"}
  I originally assumed this means the file was successfully added to the upload and not that the file was successfully uploaded.???

Now before we loaded RC 6.1.9 we simply called Upload.FinaliseUpload and assumed the "OK" there meant that the upload was successful and that uploadkey will not accept more uploads.  However we now get an error saying "METHOD_NOT_SUPPORTED_FOR_UPLOAD_TYPE".  I queried this behavior and Steve pointed out that we should never have been using it this way in the first place.  I should be using Upload.GetUploadResult.  However, every time I do AddfilesToUpload the file does upload successfully (I can see it n the application) but when I call GetUploadResult the response is always the same:   "result": {"api": "OK", "action": "UPLOAD_NOT_STARTED"}

I have tried this with blocking set to true as well as blocking set to false - makes no difference.

So having played around with this, my conclusion is that the response from AddFilesToUpload is what tells us if the image was uploaded successfully or not.  However the documentation says that this "returns a hash containing the key succeeded, a hash of client reference → IMS File Reference. Otherwise void.".  Now I do not know how to make this fail so what exactly is void?  The entire response or just the File reference?  If the latter what would I expect in place of "Succeeded"?

So the questions are: 
1.  At what stage do I know for sure that an upload has succeeded or failed?  Exactly what tells me this?  (What does the response look like for failure)
2.  We use this process for a single file upload at a time.  What should we be doing to kill that particular uploadkey and when do we do this.

ben

Third Light Staff

From: Third Light

Registered: 2013-06-06

Posts: 79

Re: Confirmation of upload succeed or fail.

Hi mdyason,

Sorry for the confusion here. This is a bit of a confusing topic as there are a number of similar options that do some very different things!

In any case:
the "synchronous" option affects whether files are processed immediately, or queued until you call StartUpload(),
the "blocking" option affects whether the API calls wait for the processing of the transferred files to complete before returning.

You're specifying "synchronous" == true, and presumably not specifying "blocking" so this defaults to true.

With a synchronous, blocking upload, your call to AddFilesToUpload() will transfer the file /and/ process the file before returning from the call. In this mode, the response you are getting tells you for sure that the file upload succeeded. If there was an error with the processing, then your client reference just won't appear in the response. Note made about how that isn't particularly helpful for error tracking. The void return from AddFilesToUpload() is used when the upload is in non-synchronous mode i.e. the file is queued and there is nothing else to report.

If you were using a synchronous, non-blocking upload, then you might expect AddFilesToUpload() to kick off the file processing immediately but also return immediately (non-block). I think you'd be right to expect that but I see this API call doesn't support synchronous, non-blocking. Either a bug or failure of documentation depending on your perspective. Nonetheless I have recorded this for future improvement.

I should add to the above, that there is a second method of transferring files – via the postURL returned from CreateUpload() – and this definitely does support synchronous, non-blocking.

With due respect to Steve, the GetUploadResult() method is not suitable for a synchronous, blocking upload - the point being that the response from AddFilesToUpload() will have already told you the result. You could argue that GetUploadResult() could still return the current situation, but that isn't how it is coded at present.

To kill the upload key, you should call AbandonUpload(). This will clear the uploadKey from the DB and thus prevent further use of it. The upload task will be marked as complete.

I hope that goes someway to explain the situation. If you have further questions please let me know.

Ben