list_folder_continue api recursively produces increasingly longer cursor until timeout

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