Forum Discussion

Net4nel's avatar
Net4nel
Explorer | Level 4
4 years ago

'too_many_write_operations' on 'sharingAddFolderMember'

Hi, i wrote an async automation that grant permissions to specific DB groups according to folders paths for an existing folders structure.
This structure gets built using a different automation but both are individual from each other.

on my logic i'm using multiple DB functions (by order: filesGetMetadata -> sharingShareFolder -> sharingUpdateFolderPolicy -> sharingSetAccessInheritance -> sharingUpdateFolderPolicy (owner) -> sharingAddFolderMember).

On 75% of times it's running - i'm getting an error of 'too_many_write_operations' as error in return to 'sharingAddFolderMember'.
I'm creating a list of 3-5 groups for each folder, some of the folders are exists in different paths under same mother folder. (on the other 25% it works like charm).

The whole logic is async, awaiting for each method to finish before starting the next. 

Any Idea what can cause this issue? and what should be my way of thinking when designing the solution?

Thanks!!

  • Greg-DB's avatar
    Greg-DB
    Icon for Dropbox Staff rankDropbox Staff

    This 'too_many_write_operations' error indicates "lock contention". That's 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 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 this in the Performance Guide. (That's written more for uploading files, but it has useful context.)

     

    In short, to avoid this error, you should avoid making multiple concurrent state modifications. That won't guarantee that you won't run in to this error though, as contention can still come from other sources, so you may want to implement some automatic retrying, following the 'Retry-After' header, if given.

     

    Also, note that the sharingShareFolder job itself can runs asynchronously. If you get an async job ID back, you should use sharingCheckShareJobStatus to check the status and wait until it's complete before issuing more changes.