We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
list_folder_continue api recursively produces increasingly longer cursor until timeout
We use recursive https://api.dropboxapi.com/2/files/list_folder and https://api.dropboxapi.com/2/files/list_folder/continue api endpoint to pull events from dropbox cloud from root folder. However, t...
Please open an API ticket with the account ID and a sample cursor that results in this error so we can check on that for you. Thanks!
Greg-DB
Dropbox Staff
Dropbox Staffsynology_support I just wanted to follow up here to let you know we've recently received several samples from users regarding this thread. I believe we've established enough of a pattern here that we do not require any further samples, so there's no need to send in more samples. I'll let you know if the team requests any additional information though.
We've also reached out to you directly by email, but in case you didn't see those, for reference:
It looks like this issue is related to the accounts containing a very large number of files, which can take a long time process on the server in some cases. Also, note that the processing time on the Dropbox API servers can vary over time, due to a number of factors. Unfortunately, this isn't something that API clients can directly control directly. For instance, this can depend on things like the current load on the Dropbox API servers, and what content/namespaces in the account are being processed in the call.
We've sent this along to the team to see if we can improve the performance of this, but I can't promise if/when any such optimizations would be deployed.
There are some things you may be able to do to try to handle this client-side though:
- whenever you get a 5xx like this, retry the call, respecting the Retry-After response header value, if given, or using an exponential back-off if not
- use a smaller
limitvalue on /2/files/list_folder - switch to
recursive: falseon /2/files/list_folder. Of course, we understand that this isn't ideal, as it would require client-side code changes to descend into child directories if/when needed
Hi Greg,
We continue to receive an increasing number of support tickets reporting that data isn't syncing from Dropbox to Synology NAS. Could you prioritize resolving this issue on the Dropbox end?
We've also tried the possible workarounds provided by the Dropbox team:
- use a smaller limit value on /2/files/list_folder > We adjusted it from 2000 to 100. However, the issue persists.
- switch to recursive: false on /2/files/list_folder. > Unfortunately, we can't change this part since we need to monitor the entire directory tree.
Thank you!!
- Greg-DB
hhting Thanks for following up. I'll communicate this to the team.
Regarding the
recursive: falseoption, you could still use that to list everything, but that would require you to update your code to make separate calls to /2/files/list_folder (and /2/files/list_folder/continue as needed) for each level.Also, you don't need to do this in all cases; you could have your code automatically fall back to these potential workarounds only if/when the standard way fails.
Hi Greg-DB,
In our synchronization mechanism, we need to monitor all changes across the entire directory tree. This is why we require a cursor with the `recursive: true` option for long polling and fetching delta files.
If we use the `recursive: false` option, we would be able to monitor only one folder at a time and would need to manage thousands of cursors, which is currently impractical for our setup.
Therefore, we believe that addressing this issue on Dropbox's end would be a better solution for these users.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
