You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
donaldp
6 years agoCollaborator | Level 9
Problem with GetMetadataAsync
Hi, I'm trying to test for the existence of a folder so as not to repeat myself. My understanding is that you use GetMetadataAsync and treat the folder as not there if you get an exception. (1) I'm ...
Greg-DB
Dropbox Staff
Hi Donald, there is a rate limiting system on the Dropbox API, but it's relatively generous. If you are hitting it though, the Dropbox API will return an explicit rate limiting error. It's possible you're missing that since you're not inspecting what kind of exception you're getting, as you mentioned. Likewise, there are other exceptions that can occur on GetMetadataAsync other than just 'not_found'.
Here's an example of how you can break out some of the various error cases:
try { Metadata res = await client.Files.GetMetadataAsync(path); Console.WriteLine("{0}", res); } catch (ApiException<GetMetadataError> e) { if (e.ErrorResponse.IsPath) { if (e.ErrorResponse.AsPath.Value.IsNotFound) { Console.WriteLine("Path not found!"); } else if (e.ErrorResponse.AsPath.Value.IsMalformedPath) { Console.WriteLine("Malformed path!"); } // and so on for the other .Is* methods as desired else { Console.WriteLine("LookupError: {0}", e.ErrorResponse.AsPath.Value); } } else { Console.WriteLine("GetMetadataError: {0}", e); } } catch (Exception e) { Console.WriteLine("Some other error: {0}", e); }
donaldp
6 years agoCollaborator | Level 9
My apologies. I disovered I'd forgotten to await the delay, so it wasn't actually waiting for it. Oops! Now that I've rectified that, the code is working correctly... sometimes. I originally had a 500ms wait between each item (since Bing image search limited to 3 per second), and I still get issues at that speed (500ms later, a Dropbox folder which has been created is still being reported as not existing yet), but I decided to try having a 350ms delay between each image, and the code is working correctly at that slower speed (though otherwise that is un-necessarily slow, since I should only need to wait for each item, not each image). Also got rid of most, but not all, of the retry exceptions at the slower speed. You said there was a generous API call limit - what is it? (I've not seen it mentioned) I can try pacing my code to that and see how it goes. So, there's still an issue, but I have a work-around for the time being.
- Greg-DB6 years agoDropbox Staff
Thanks for following up. You shouldn't be getting 'not_found' for a path that already exists, but if you are calling to get the metadata immediately after the item is created (e.g., in the case of a duplicate in your input list), there is a chance that can happen. The CreateFolderV2Async method (as well as others, such as the upload methods) return the metadata for the new item, so I recommend keeping track of those results and de-duplicating locally, as that would likely be faster and less error-prone in this scenario.
Alternatively, you can just allow CreateFolderV2Async (assuming that's what you're using) to run whenever you are getting 'not_found', and catch the CreateFolderError on that. I.e., to ignore it if it contains a WriteConflictError.Folder.
Anyway, a RetryException isn't actually explicit rate limiting. (That would be RateLimitException.) That just indicates an issue on the Dropbox servers so you can have your app retry the request if you wish.
- donaldp6 years agoCollaborator | Level 9
"Alternatively, you can just allow CreateFolderV2Async (assuming that's what you're using) to run whenever you are getting 'not_found', and catch the CreateFolderError on that. I.e., to ignore it if it contains a WriteConflictError.Folder"
I think that's the best solution. Thanks for the suggestion!
In the meantime, working on implementing that, I'm now hitting the ratelimit exceptions, so can you please let me know what the allowed rate is so that I can pace my code appropriately? Thanks.
- Greg-DB6 years agoDropbox Staff
We don't document any specific numbers for the rate limit. Apps should be written to dynamically catch and handle any rate limiting errors instead of hard coding limits. You should use the returned RateLimitError.RetryAfter value to see how long to wait before retrying.
Also, note that not all RateLimitException indicate explicit rate limiting exactly. You should check the RateLimitReason in RateLimitError.Reason to see why the request couldn't be serviced at that time. RateLimitReason.TooManyRequests indicates explicit rate limiting, but RateLimitReason.TooManyWriteOperations just indicates "lock contention". You can read more about lock contention in the Data Ingress guide.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.5,917 PostsLatest Activity: 11 days ago
If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!