I have a few folders on Dropbox. I have a client app that observes each folder with "2/files/list_folder/longpoll". If a change is detected, I process the change with "2/files/list_folder/continue". This is working fine so far.
Now I encountered this issue:
I share one of these folders with another account via the Dropbox web site. The longpoll for this folder returns successfully and tells me there is a change. I call "2/files/list_folder/continue" with the latest cursor for this folder. The request returns with a response including the error tag "not_found".
My question is: Why returns Dropbox a "not_found" in this case? The folder is obviously still there if I'm looking at my Dropbox account, it was just shared.
If I repeat the "2/files/list_folder/continue" request some times (e.g. 3 times) in this situation, the folder is eventually found again. So there seems to be a small range of time after a sharing action, where "2/files/list_folder/continue" requests are not handled correctly.
I first observed this issue a few months ago in April 2019. The issue did not show up in 2018.
So is this expected behaviour or a bug at your side?
Most sharing will be completed synchronously. Large folders will be completed asynchronously. To make testing the async case repeatable, set `ShareFolderArg.force_async`. If a ShareFolderLaunch.async_job_id is returned, you'll need to call check_share_job_status until the action completes to get the metadata for the folder.
In this case, it sounds like the sharing action is happening asynchronously and that's causing your files/list_folder/continue call to come up empty until it finishes.
If you're sharing through the public API, then there is a mechanism to deal with this particular situation. However, using the UI in combination with the API will probably keep throwing this error.
Hope that helps! Reply if you're still having issues. My colleague gets back from PTO tomorrow and you may get a different answer.
The folders I share are really small (just a few KiloBytes). I also just created them for the test. It is also not entirely reproducibly. It seems like on some days this happens more often then on others. Maybe it's related to Dropbox workload.
Is it defined from what size on a folder is shared asynchronously via the Dropbox Website?
And if my small folder is shared asynchronously, is it really expected, that "files/list_folder/continue" will return a "not_found" error? Maybe it would be better, if it would return empty, how you described it (and not with an error).
But actually I would expect the longpoll to respond _after_ the asynchronous sharing is completed, not when it is started. Then my "files/list_folder/continue" would not run in this problem at all.
I'll be happy to try to get some more clarity on this issue for you, but it would be helpful to get some more information so I can be sure I understand exactly what parameters you're using and what behavior you're seeing. Can you share the actual HTTP requests and responses for the API calls you're making, including the request and response bodies? Just be sure to redact the access token of course. If you'd prefer to share privately, please feel free to open an API ticket. Thanks in advance!