Too many write operations when moving a folder

bcd_nyc

{"error_summary": "too_many_write_operations/...", "error": {"reason": {".tag": "too_many_write_operations"}}}

 

I am getting this error when using the V2 API (via PHP & curl) to move a folder with about 30 files in it-- I'm confused because it doesn't seem like this is a big enough operation to trigger an error.

 

One thing to note is that the destination folder already exists with identical files in it. I expect that the files in the destination should either be duplicated or overwritten and the source deleted, but instead I just get the error above. It seems like this behavior is inconsistent-- sometimes it works OK and sometimes I get an error.

 

 

This is what my folder structure looks like: 

 

-/images/1099

--img1.jpg

--[...]

--img30.jpg

 

 

-/archive/accountname/ordernumber/1099

--img1.jpg

--[...]

--img30.jpg

Greg-DB

The error 'too_many_write_operations', indicates that the operation failed due to "lock contention". This isn't explicit rate limiting, but rather an inability to perform multiple state modifications in the same account at the same time. 

This can vary over time, based on how much activity is occurring in the account. Note that the simultaneous changes can be from either the app itself, or other clients acting on the account. (E.g., the official Dropbox desktop client, another API app, a Dropbox mobile app, etc.)

If you haven't already read it, I recommend the data ingress guide, which goes over this in more detail:

https://www.dropbox.com/developers/reference/data-ingress-guide 

 

Also, for moving multiple files, it's best to use /2/files/move_batch in order to move multiple at a time:

 

https://www.dropbox.com/developers/documentation/http/documentation#files-move_batch

 

This can help avoid lock contention with your own calls (e.g., if you were making multiple calls to the non-batch version) by sending the operations all together. Note that it's always possible that some other client is making changes though, so you should still catch any 429 or 503 and retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not.