list_folder_continue -> 504 errors

I should also add that when re-running my script, calling list_folder_continue with the most recent cursor prior to catching the InternalServerError, takes a very long time to get going again, with the same API request attempts:

2018-09-25 08:59:14,422 - dropbox - INFO - Request to files/list_folder/continue
2018-09-25 09:00:44,445 - urllib3.connectionpool - DEBUG - https://api.dropboxapi.com:443 "POST /2/files/list_folder/continue HTTP/1.1" 504 35
2018-09-25 09:00:44,446 - dropbox - INFO - HttpError status_code=504: Retrying in 2.0 seconds
2018-09-25 09:00:46,445 - dropbox - INFO - Request to files/list_folder/continue
2018-09-25 09:02:16,463 - urllib3.connectionpool - DEBUG - https://api.dropboxapi.com:443 "POST /2/files/list_folder/continue HTTP/1.1" 504 35
2018-09-25 09:02:16,464 - dropbox - INFO - HttpError status_code=504: Retrying in 3.8 seconds
2018-09-25 09:02:20,277 - dropbox - INFO - Request to files/list_folder/continue
2018-09-25 09:03:50,319 - urllib3.connectionpool - DEBUG - https://api.dropboxapi.com:443 "POST /2/files/list_folder/continue HTTP/1.1" 504 35
2018-09-25 09:03:50,320 - dropbox - INFO - HttpError status_code=504: Retrying in 7.6 seconds
2018-09-25 09:03:57,961 - dropbox - INFO - Request to files/list_folder/continue
2018-09-25 09:05:27,982 - urllib3.connectionpool - DEBUG - https://api.dropboxapi.com:443 "POST /2/files/list_folder/continue HTTP/1.1" 504 35
2018-09-25 09:05:27,984 - dropbox - INFO - HttpError status_code=504: Retrying in 0.3 seconds
2018-09-25 09:05:28,278 - dropbox - INFO - Request to files/list_folder/continue

Thanks for getting back to me Greg.

I'd rather not have to go with #2 because this implies I can't reliably check for changes in the folder at a later stage using the cursor obtained from `files_list_folder_get_latest_cursor`. i.e. #1 would require me to traverse the entire folder each time I want to check for changes (or require me to store multiple cursors for sub-directories etc.).

I've already been `running files_list_folder` with `limit` set to 500, and each time the internal server error occurs after about approx 310,000 files/folders. So I can almost predict when the error will occur.

I'll try it again with `limit` set to 50 and report back tomorrow.

Is this issue related to the number of files in a folder, i.e. limit -> 1 as number of files -> infinity? If so, I'll stop using cursors altogether.

Yes, this is likely related to the number of files, but possibly also the amount of file activity. (So, yes, as the number of files goes to infinity, the working limit would go down.)

Hi Greg-DB,

So, after about 270,000 files/folders, I received an Internal Server Error (with `limit` set to 50), and can't seem to get going again with the cursor I stored prior to the collapse.

I guess I have to conclude that cursors aren't reliable for traversing folders with many files and sub-folders.

I'm not even sure its worth re-designing my app to use cursors for checking the state of each sub-directory, so I'll have to go with your #2 each time.

Thanks for trying that, and my apologies for the trouble. I'll follow up here when I have any updates on this issue.

Hello, any updates on this issue ? The issue is not solved, we still face this issue

In addition to the techniques mentioned in this thread, I would also suggest traversing with include_mounted_folders=false.

Mounted folders refer to folder shares or team folders. With that option, the mount point (shared folder id) is still returned in the output, but not the share's content.  You could then traverse the share independently with a different cursor.

This is particularly helpful for large team folders or scenarios with a lot of large shares.

We have updated our reference guides with best practices since this thread started, check them out here.

I don't have a specific update on the 504 error the original poster mentioned - are you seeing the 504 code, or something else?  Including a little more detail on the error response you're seeing may help.