Child Item

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/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?

Thank you for your help!

Find more posts tagged with

API

Abuse

Comments

TaylorKrusen

Has 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.

Thomas_

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

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!