You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.

Forum Discussion

Ghislain Sommervogel's avatar
Ghislain Sommervogel
Helpful | Level 5
3 months ago

.NET API : DropboxClient.Sharing.AddFolderMemberAsync() no more completing

Hello,

Since yesterday, DropboxClient.Sharing.AddFolderMemberAsync() has stopped working (while all other API calls still work). Basically, I'm just creating a new team folder and then assigning 4 members in one single API call. That second operation fails, although it was working 2 days ago and the source code was not modified in between. The problematic behavior changes from time to time.

 

Most often, the API call simply doesn't return. The executing program remains indefinitely at the following statement : await _client.Sharing.AddFolderMemberAsync(arg);
In that case however, in the web admin console, I can see the required members have been correctly added. But apparently the program receives no notification of the correct completion and therefore hangs.

 

In some other cases, after about 60 seconds I get a "too_many_write_operations" error. I don't know how I'm supposed to handle this error. Currently, I just resend the instruction. After a new 60 seconds delay, I then receive a retry exception with the following html message:
<!DOCTYPE html>
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Dropbox - 504</title>
<link href="https://cfl.dropboxstatic.com/static/metaserver/static/css/error.css" rel="stylesheet" type="text/css"/>
<link rel="shortcut icon" href="https://cfl.dropboxstatic.com/static/images/favicon.ico"/>
</head>
<body>
<div class="figure">
<img src="https://assets.dropbox.com/www/en-us/illustrations/spot/target-miss.svg" alt="Error: 504"/>
</div>
<div id="errorbox">
<h1>Error (504)</h1>Something went wrong. Don't worry, your files are still safe and the Dropbox team has been notified. Check out our <a href="https://status.dropbox.com">Status Page</a> to see if there is a known incident, our <a href="https://www.dropbox.com/help">Help Center</a> and <a href="https://forums.dropbox.com">forums</a> for help, or head back to <a href="https://www.dropbox.com/home">home</a>.
</div>
</body>
</html>

Can you please help in troubleshooting the case? Best regards,
Ghislain

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

    The .NET SDK method calls should eventually either return a result or raise an exception (e.g., if the connection takes too long and times out), but depending on how long the calls take, it can take some time to do so and would hang in the meantime.

     

    Like Здравко said, 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. 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. 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.

     

    Similarly, a 504 error indicates a transient server availability issue and should be retried.


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

    • Ghislain Sommervogel's avatar
      Ghislain Sommervogel
      Helpful | Level 5

      Hi Greg,

      Like I said, imho there is no activity that could explain the error here. The shared folder has just been created and there is absolutely no activity on my dropbox account on the desktop or on the web. The only activity for the folder / account consists in a single API call for adding 4 members to the newly created folder. If that only can result in that kind of exception, I wonder whether the API is really usable for automating complex tasks.

      But forget about the "too_many_write_operations", I worry MUCH more about the other behavior : the "await AddFolderMemberSync" that never ends. Requested changes are made right after the API call (I can view the correct memberships in the admin console), but even after one hour  the application still "await" the API call. If some calls to the API never return (no KO nor OK nor exception... just nothing), it makes all programming work uneffective and the full API useless! What can be done to monitor what happens? Should I open a support ticket? Thanks for your advice.

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

        The SDK methods should always either return or throw some error, but if it's blocking for a long time, it may be helpful to inspect the requests/responses directly as Здравко said.

         

        We're also happy to take a look on our side if you'd like. Feel free to open an API ticket here at your convenience. If you do so, please share as any/all detail that you can, including steps/code to reproduce the issue, relevant app ID, member ID, namespace ID, and timestamps of calls. Be sure to redact any access tokens, refresh tokens, or app secrets though. Please also include this thread URL for context. Thanks! 

  • Здравко's avatar
    Здравко
    Legendary | Level 20

    Ghislain Sommervogel wrote:

    ...

    In some other cases, after about 60 seconds I get a "too_many_write_operations" error. I don't know how I'm supposed to handle this error. Currently, I just resend the instruction. ...


    The cases, described by you, usually happen when there is some sort of overload on particular namespace, resulting from too many calls (write operations in your case, but may be others too). Try optimize your application calls as much as possible - use batch operations when you have to do many operations at once, for instance. Sometimes there is possible optimization of the application algorithm to reduce meaningless operations if any (review your code - there might be some things that are not needed and application can continue work without such things). Of course, too many calls may originate from different applications (not only from one where error appears). So you have to always be ready to handle such an error - response status 429 or any 5xx. Like you do, resend the instruction while bear in mind the possible backoff "wish" coming with the error (either in response body or as response header) and even when it's missing, organize your own exponential backoff. After some reasonable number of tries you may need to stop looping and gently inform/ask the user to try later while keep the application state consistent.

    Hope this gives direction.

    • Ghislain Sommervogel's avatar
      Ghislain Sommervogel
      Helpful | Level 5

      Hi Здравко,

       

      Many thanks for your advices.

       

      The "too_many_writes_operation" is a little bit surprising, considering the fact that I just created the namespace and that I use only a single statement after that. Obviously there is absolutely nothing to optimize here and I'm the only one writing something in that folder.

       

      But anyway, the most perturbing behavior is the first one (and it is by far the most frequent) : my code stops executing after the "AddFolderMemberAsync" call ("await" never ends), although this procedure has been working fine for a few days. I'm wondering whether there is a "reset" that could be done somewhere in order to solve the problem.

      Cheers,

      Ghislain