We’re Still Here to Help (Even Over the Holidays!) - find out more here.
Forum Discussion
REST API v2: /list_folder/continue returns not_found error after changing the sharing state
Hi Dropbox-Team,
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/l...
TaylorKrusen
Dropbox Staff
Dropbox StaffHas the folder being shared grown considerably in size from 2018 to 2019?
I think this is expected behavior, but it's not obvious what is happening since you're triggering the share from the UI rather than the API.
According to the API docs on the /sharing/share_folder endpoint,
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.
Thanks for the response.
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.
So the issue is not completely clear to me yet.
- Greg-DB
Dropbox Community Moderator
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!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
