We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
System.Threading.Tasks.TaskCanceledException: A task was canceled.
We have 500 machine which upload file at same time. We are getting RateLimitException. We are doing a retry after waiting rateLimitException.ErrorResponse.RetryAfter seconds. to test this. I came ...
In general modifying the folder should not affect probability for exception appearing, but cannot prevent it. Some decrement may happen if different files/folders appear in different namespaces (namespaces are locked independently, so less likely compete), but better don't rely on.
Again, try to schedule the uploads in non overlap way and handle the possible exception in proper way. Example of such exception handling (again just example and far from optimal) follows:
private readonly int retryLimit = 20; ... var backoff = 0; var rand = new Random(); var commitInfo = new CommitInfo(filePath.Substring(filePath.LastIndexOf('/')), WriteMode.Overwrite.Instance, false); for (var i = 0; i < retryLimit && !string.IsNullOrEmpty(sessionId); ++i) { if (backoff != 0) { Console.WriteLine("Ограничение при завършване на файл {0}. Нов опит след {1} милисекунди...", commitInfo.Path, backoff); Thread.Sleep(backoff); } lastCursor = new UploadSessionCursor(sessionId, (ulong)fileStream.Length); memStream = new MemoryStream(buffer, 0, 0); try { await dbx.Files.UploadSessionFinishAsync(lastCursor, commitInfo, body: memStream); sessionId = string.Empty; } catch (RateLimitException rateLimit) { backoff = (int)(backoff * 1.1); backoff = Math.Max(backoff, rateLimit.RetryAfter * 1000); backoff = Math.Max(backoff, 1000); backoff += rand.Next(500); } } if (string.IsNullOrEmpty(sessionId)) { Console.WriteLine("Качването на {0} приключи \ud83d\ude09.", commitInfo.Path); } else { Console.WriteLine("Неуспешно завършване на файл {0} след {1} опита \ud83d\ude15!", commitInfo.Path, retryLimit); }The above just shows how my advices (from previous page) can be implemented. Here sessionId represents a session ready for finishing (i.e. content uploaded already).
Hi Engg,
It's better to trace the state for figuring out why your code falls to such an exception. To do it better, avoid indefinite recursions (your code can fall very easy in relatively deep recursion - something that's not a good practice). Whenever possible use iterations instead of recursions (in the particular case recursion usage is meaningless - only makes the things more complex to debug). Why at all are you using recursion? 🤷
About rate limiting, this is because you make too many calls that change the target namespace state simultaneous. Every call that add/change/delete something in particular namespace folder tree perform such a change. You can easy decrease this number by upload all (or in groups) you files in batch(es). You can upload many files without change anything in target namespace folder tree and once entire group is uploaded (but still invisible) finish upload for all files at once (so just one change in the folders tree for all files). So you will be able add your files in one (or few - depending on total files count) step(s) that will decrease probability for rate limit error to negligible. 😉
Hope this helps.
In my case I have 500 machine and in each machine we have window service which job is upload the file to dropbox. All the 500 machine uploading files to dropbox at same time(Morning). How to huddle this. How to decrease this number by upload in this case.
Most of the system the uploading is getting failed. I'm getting following exception.
Dropbox.Api.RateLimitException: too_many_requests/...
at Dropbox.Api.DropboxRequestHandler.<RequestJsonString>d__2f.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Dropbox.Api.DropboxRequestHandler.<RequestJsonStringWithRetry>d__1a.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Dropbox.Api.DropboxRequestHandler.<Dropbox.Api.Stone.ITransport.SendUploadRequestAsync>d__d`3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Odin.Compute.OdinDatabaseBackupManager.Program.<ChunkUpload>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Odin.Compute.OdinDatabaseBackupManager.Program.<Upload>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Odin.Compute.OdinDatabaseBackupManager.Program.<Run>d__5.MoveNext(); Request Id: 18b89669a35b4234bb4592f84d61c048
To test this I came up the code that I shared before. Can you share me any code for reference it will be helpful.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
