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 StaffPlease 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-DBDropbox Staff
Dropbox StaffThe team routinely fixes issues they find, but I don't have a specific reference for this in particular as we didn't have a sample to check on for you. Did you open a ticket for this? If so, you should have received an update on that ticket, but let me know if not and share the ticket number and I can look into it for you.
Hi, Greg
I haven't filed a ticket yet. I'll keep observing and if the cursor times out again, I'll then do so.
Thank you for the support~!
Best regards,
Ethan Fang
- Greg-DB
synology_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!!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
