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, the cursor keeps getting longer, start from about 6800 characters, and when it increases to 7400 characters, it keeps getting 504 timeout, and returns the following html content. Moreover, the user has a normal account instead of teamspace.
Thank you~!Best regards,
Ethan Fang
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!
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,
@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:
limit
recursive: false
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:
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!
