Child Item

/move_batch/check_v2 returns too_many_write_operations for some files

I use https://api.dropboxapi.com/2/files/move_batch_v2 to move files and get the `async_job_id`. Then I use https://api.dropboxapi.com/2/files/move_batch/check_v2 with `async_job_id` to check the process status, and when the process was done, I get the response which includes `too_many_write_operations` error for some files, the others are ok.

Find more posts tagged with

API

Abuse

Comments

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 backend. This is a technical inability to make a modification in the account or shared folder at the time of the API call. 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 here. The app will need to be written to automatically handle this error.

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

Shahen

Ok, thanks for your answer. But we send move_batch/check_v2, we receive only 'too_many_write_operations' for some files without id or name. Does it mean that I need to move all files again using 'files/move_batch_v2'? Can't we detect all the files which were failed.

Здравко

@Shahen wrote:
... But we send move_batch/check_v2, we receive only 'too_many_write_operations' for some files without id or name. Does it mean that I need to move all files again using 'files/move_batch_v2'? ...

Hi @Shahen,

Calling 2/files/move_batch/check_v2 gives you the status of a scheduled operation identified with the id provided. It doesn't matter how many times you will call this API, doesn't matter the status (in progress or completed) - it will always refers to the same operation (no new one gets launched). To initiate new move try, you have to perform 2/files/move_batch_v2 API call again, of course.

@Shahen wrote:
... Can't we detect all the files which were failed.

🤔That would be a good feature request. As a workaround, you can perform completed move entries collecting and exclude them out from the initial request before the retry. 😉 Not very convenient, but it's something.

Greg-DB

When the returned RelocationBatchV2JobStatus is 'complete', it will contain a RelocationBatchV2Result with a list of RelocationBatchResultEntry as the 'entries' property. Each RelocationBatchResultEntry will be either 'success' or 'failure', indicating the result for that particular file. This list corresponds to the files originally supplied to /2/files/move_batch_v2 in the 'entries' parameter, in the same order.