FALSE POSITIVE REPORT -- this turned out to be a false positive with an overflow of the cursor length on our side causing repeat calls. Combined with the unexpected "delete" folder that occurs when you share a folder, we thought this was a bug, but soon found the root cause.
SCENARIO:
1. User Create a folder.
2. User Share the folder with a 3rd party.
3. 3rd party adds a shared folder to account.
4. 3rd party changes the content in a folder, such as adding a folder.
5. Webhook is generated on Users account.
PROBLEM:
The cursor loops with the same data over and over. The data is also incorrect, its the path of the shared folder, and not the path of the content changed by the user.
EXAMPLE:
Folder example: /MyFolders/ShareFolder is shared with 3rd party User.
3rd party user adds a folder: /MyFolders/ShareFolder/3rdPartyCreateFolder
Webhook received by app of the original user, and we call: https://api.dropboxapi.com/2/files/list_folder/continue
{"entries": [{".tag": "deleted", "name": "sharefolder", "path_lower": "/myfolders/sharefolder", "path_display": "/MyFolders/ShareFolder"}, {".tag": "folder", "name": "sharefolder", "path_lower": "/myfolders/sharefolder", "path_display": "/MyFolders/ShareFolder", "id": "id:<id>", "shared_folder_id": "<share id>", "sharing_info": {"read_only": false, "shared_folder_id": "<share id>", "traverse_only": false, "no_access": false}}], "cursor": "<cursor>", "has_more": true}
ODDITIES:
We never get the notice about "3rdPartyCreateFolder" being created.
The webhook says it "has_more", so we keep calling, (different cursors) but its always the same result, for 10 or 20 times in a row.
The webhook itself says the folder was 1) deleted, and then 2) changed, when in reality it wasn't changed at all or deleted.
CONCLUSION:
This issue seems to be specifically related to webhook changes on shared folders being systemically broken. Please resolve this as soon as possible.