list_folder_continue api recursively produces increasingly longer cursor until timeout

Have you guys fixed anything? The same cursor stops timeout today.

The 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

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 limit value on /2/files/list_folder
• switch to recursive: false on /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!!

hhting Thanks for following up. I'll communicate this to the team.

Regarding the recursive: false option, 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.

hhting Thanks for the context!