Child Item

.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

Find more posts tagged with

Comments

Здравко

@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

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

Greg-DB

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

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.

Здравко

Hi @Ghislain Sommervogel,

The API always returns (with either success or some error). What you're talking about is Dropbox .Net SDK though - make difference. 🙂 It's different thing and, by idea, it's supposed to make your life easier. As seems, in your case, something makes the SDK to think API call never finish and that's why it blocks. This SDK always returns when entire request finished, for all non download requests (as is in your case), something that makes debugging of such issues difficult unfortunately. You may want to pass your own HTTP client, with customized handler, that will let you follow what exactly happens or to re-implement on your own the particular call only. If I am in your shoes, I will do that (one of the both). In such a way you will have much more detailed view of what happens and see where exactly is the issue. Also, you will be able see the request ID that may help further debugging (.Net SDK provide it on clearly identified error only). Do it! 😉

Good luck.

Greg-DB

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!

Ghislain Sommervogel

Thank you @Здравко for the advices. I'm not used to programming direct calls to APIs using http clients, but I'll give it a try 😉

Ghislain Sommervogel

Thanks Greg. The API call works again. It it happens to freeze again, I'll probably open a ticket for help. Have a nice day.