dropbox create_folder_v2 api keeps getting 429 too_many_write_operations without giving retry_after

synology_support

Hi,

We're using dropbox create_folder_v2 api to upload folders, and there are 1.4 million folders to upload. However, recently, it keeps getting 429 too_many_write_operations error without giving the Retry-After value, and we don't know how to control the upload rate.

According to the performance guide, it should responds us with Retry-After. Moreover, is there any other way to create_folder concurrently without leading to 429 error?

https://developers.dropbox.com/zh-tw/dbx-performance-guide

Thank you,

Best regards,

Ethan Fang

Greg-DB

If there are multiple changes at the same time in the same account or shared folder, you can run in to this 'too_many_write_operations' error, which is "lock contention". 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. Since this is not an explicit rate limit enforced by Dropbox, there isn't a particular Retry-After value that it can specify to guarantee that the next call will work; it's just based on whether or not there is other concurrent activity (which is not something Dropbox can control or predict). In lock contention cases like there where Retry-After is not specified, you can assume a value of 0, but it would be good to implement an exponential backoff.

 

For reference, 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.

In short, to avoid this error, you should avoid making multiple concurrent state modifications and use batch endpoints where possible, such as /2/files/create_folder_batch. 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.