6 Replies Latest reply on Feb 25, 2014 4:42 PM by levw

    Sending errors back to Jive from the external storage


      Hi, Lev Waisberg, Yuval Varkel


      We're having some issue when we try to send errors back to Jive. The workflow is the following:

      · The user upload several files from Jive to a group connected to the ESP.

      · Then the files are deleted (specifically the latest version of the file) from the ESP without Jive being notified about this (this is yet to be implemented)

      · The user check those files from Jive, but can't see nor download the file

      · The user tries to delete these files from Jive but an unexpected error occurs


      The problem is that those files can't be deleted by the user and if there are several of these "broken" files the group can't be deleted either. The only solution is to delete the files from the admin console one by one.


      I've been able to reproduce it consistently when the ESP sends back the error message. If the file can't be obtain because is missing I'm sending a http 500 error with the following content:

      {"reason":"RESOURCE_OUT_OF_SYNC","message":"Couldn't get the binary file"}

      Although the ideal situation should be sending a notification to Jive, there could be errors in the ESP or network issues that could prevent the notification being sent or the notification might be lost. In this case Jive should allow the user to work normally.


      How can we deal with this situation?



        • Re: Sending errors back to Jive from the external storage

          Any update on this?


          Mark Weitzel, we're blocked here, and the user experience with the current implementation is bad

          • Re: Sending errors back to Jive from the external storage

            When a user deletes a document from Jive we call the "trashFile" resource on your service.

            So what is the response you return for the "trashFile" request ?

            If that is an error response then this is the cause for the unexpected error.


            You can send a success response as if the file has been actually trashed.

            Although a better solution would be to identify this situation (when you receive a request such as trash or download for a deleted file)  

            and re-send the delete notification to Jive.

              • Re: Sending errors back to Jive from the external storage

                You're right. I was sending an error response for the trash request.


                The problem is that the information of the file is deleted, including the external ids of the file and / or version and the resources, so I cannot send a good success response because the external Ids will be empty and the version information will be missing.


                If I can keep the external Ids, I can send a success response (with the external Ids and the resources), but the version information (content-type, file name and size) will be missing. However, if then the file is untrashed, should we send an error or send a success (with the available info)?



                • Re: Re: Sending errors back to Jive from the external storage

                  Keeping with the same scenario as described above, now I'm returning the following information when the last version of the file has been deleted from the ESP:


                  There is no version information included because we cannot obtain it, and the file information is generated based on the request.


                  It seems that Jive process the trash response correctly, but the problem now is that the file isn't recoverable so the "untrashFile" request will always fail with an error.


                  Is there any way to tell the Jive server that the file cannot be recovered without sending a notification? Is it a good idea to remove the "untrashFile" resource from the response?