We have an iPhone app that is configured to upload files to dropbox.
Our dropbox account ran out of space, but the upload from the app finished without error message so we did not know the account was out of space.
Later on we upgraded our account so that there would be enough space, but the files have not appeared.
We wrote the app.
We would like our app to accurately detect that the files did not upload and give a message to the user so they can get the server issue fixed and then reupload the files.
We reviewed the code and do not see what we are doing wrong that this was not reported as an error.
I would like dropbox to check their logs and tell us what error message they returned to the app for the failed attempt. They are telling us there is nothing they can do because the files did not upload. I have a hard time believing that they do not have a log of all attempts.
Please do not mark this as solved as that apparently locks replies. I will mark it as resolved when someone solves it.
If you tell me that the logs of the failed attempts are not possible, then please state why you believe that; It seems very strange that that would not be logged.
Thanks for the post. The expected behavior when uploading via the API to an account when the account is out of space is an error response from the API, that the app can handle as desired (e.g., to surface an error message to the user, and retry later, etc.)
For API v1, the error response for this case has a 507 status code. For API v2, e.g., using /2/files/upload, it is a 409 path/reason/insufficient_space. Likewise, for /2/files/upload_session/finish, it's 409 path/insufficient_space. (These are converted into the respective response error types in the various SDKs.)
Whether or not the file data for failed API upload calls like this is stored on Dropbox's side depends on what API functionality you're using. API v1 doesn't store the data for the failed upload, so it can't be restored via Dropbox and would instead need to be uploaded by the app when the account has available space. In API v2, we do offer a mechanism for committing the failed upload without re-uploading the data within 48 hours, by supplying the "upload_session_id" returned by the error to /2/files/upload_session/finish.
I just tested uploading to an account that's over quota using both API v1 and API v2, and it is working as expected for me for both.
If you need help with programmatically catching this error specifically, please let me know which SDK you're using (if any) and I'll be happy to help.
If you're seeing any unexpected behavior, we'll be happy to look into it, but we'll need some more information. In that case, please reply with:
- the name or key of the API app
- the name and version of the platform and SDK/library you are using, if any
- the steps to reproduce the issue
- the full text of any error or output you're getting
- the relevant code snippet(s)
If you'd prefer to share those API details privately, feel free to open an API ticket here instead:
The above is for help with the API itself, but for help investigating activity on a specific user account, you can have the affected user(s) contact support here:
Hijacking this thread for a moment, I've been using the [client.fileRoutes batchUploadFiles] method from https://github.com/dropbox/dropbox-sdk-obj-c and I can't see how to get at the 409 error response.
In the response block both finishBatchRouteError and finishBatchRequestError are nil and [fileUrlsToRequestErrors count] = 0.
Also iterating over the fileUrlsToBatchResultEntries and checking the
DBFILESUploadSessionFinishBatchResultEntry values I only see DBFILESUploadSessionFinishBatchResultEntryFailure.
Is there any way to check for a 409 error response when using this API?
@Steve L.26 The batchUploadFiles method isn't a direct API call, but rather a convenience method built to wrap the various upload sessions calls, so it doesn't directly expose the API errors. It instead exposes different error cases via the different values in the overall response block that you mentioned.
If you want more control over the error handling, you can use the upload sessions calls directly. The SDK is open-source, so you can see and borrow from the batchUploadFiles implemantation here if you want.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!