Dropbox.Api.RateLimitException when using CopyV2Async

Question

I am experiencing Rate limit errors when using CopyV2Async

I am uploading a folder with sub folders but there are only 24 files in 11 folders

Is there a way to avoid these exceptions as I am forced to use a retry loop after catching the exception.

It nearly always succeeds after the first exception.

The code is one line:

var result = await objDbx.Files.CopyV2Async(szFolderToCopyFrom, szThisBackupSubFolder, true, true, true);

szFolderToCopyFrom is the folder on the windows machine and szThisBackupSubFolder is a new target folder on Dropbox

(Which immediately replicates back to the windows machine - I know it's odd, but the code works on dot maui so is across devices and so needs to work on IOS also which does not replicate)

Greg-DB · Accepted Answer

@JohnStrudwick The Dropbox API does have a general rate limiting system that applies to all endpoints. Also note though that if there are multiple changes at the same time in the same account or shared folder, you can run in to "lock contention" (which uses the 'too_many_write_operations' tag). That's not explicit rate limiting, but rather a result of how Dropbox works on the back-end. This is a technical inability to make a modification in the account or shared folder at the time of the API call. This applies to all account types. This error indicates that there was simultaneous activity in the account or shared/team folder preventing your app from making the state-modifying call (e.g., adding, editing, moving, copying, sharing, or deleting files/folders) it is attempting. The simultaneous activity could be coming from your app itself, or elsewhere, e.g., from the user's desktop client. It can come from the same user, or another member of a shared folder. You can find more information about lock contention and optimizations you can make here.

In short, to avoid this error, you should avoid making multiple concurrent state modifications and use batch methods where possible, such as CopyBatchV2Async like Здравко mentioned. That won't guarantee that you won't run in to this error though, as contention can still come from other sources, so you should also implement error handling and automatic retrying as needed.

I recommend referring to the error documentation and Error Handling Guide for more information.