from_lookup/not_found

[ddcjoee]

Hello,

I am running into an interesting issue when trying to copy a file from one shared folder to another. I was receiving a response that the file could not be found with the path I provided. I would get this error:

{

  "error_summary": "from_lookup/not_found/..",

  "error": {

    ".tag": "from_lookup",

    "from_lookup": {

      ".tag": "not_found"

    }

  }

}

I thought that was odd since i could see the file in the web ui. I then tried a get metadata call using the exact path that was returning the error above for copying, and it returned the files metadata without issue. The file's path also shows up in a list folder call. So everything I do seems to indicate thsi file exists, but when I go to copy, it suddenly does not exist. Has anyone ran into anything similar? 

[Greg-DB]

I'll be happy to help with any issues you're having with the Dropbox API, but I'll need some more information. Please reply with:

• the name and version number of the SDK/library you are using, if any
• the steps to reproduce the issue, including relevant code snippet(s), but don't include any access or refresh token(s)

[brian q.]

Just saw a similar type or error as this.

Using the HTML api interface directly

Error response is: {"error_summary": "not_found/...", "error": {".tag": "not_found"}}

The process of doing this is 

a) generate a copyref, then  (aka from https://api.dropboxapi.com/2/files/copy_reference/get

b) use it in a post to https://api.dropboxapi.com/2/files/copy_reference/save

Tokens are valid (all using new short lived tokens).  

The function works on basically all our users except one test case at this time (aka a problem account)

Here's the copyref failing as I write this:

create the reference

{"path":"id:Hs9eoD0tX5UAAAAAAAAADg"}
{"metadata": {".tag": "folder", "name": "TheDishEpisode_SHR_F178_EN_US_20_2K_20220926_AutoDCP_SMPTE_OV", "path_lower": "/dcps/thedishepisode_shr_f178_en_us_20_2k_20220926_autodcp_smpte_ov", "path_display": "/dcps/TheDishEpisode_SHR_F178_EN_US_20_2K_20220926_AutoDCP_SMPTE_OV", "id": "id:Hs9eoD0tX5UAAAAAAAAADg"}, "copy_reference": "AAAAALfD6UEyOG5oaHZqYjZlY3M", "expires": "2052-09-22T22:00:35Z"}

Actually do the copy with the above refernce

{"copy_reference":"AAAAALfD6UEyOG5oaHZqYjZlY3M","path":"\/deliverables\/tciff2022\/d1\/adam@adambarta.com\/TheDishEpisode_SHR_F178_EN_US_20_2K_20220926_AutoDCP_SMPTE_OV"}

And the results

{"error_summary": "not_found/.", "error": {".tag": "not_found"}}

[Здравко]

Hi @brian q.,

Did you something to the source folder "/dcps/TheDishEpisode_SHR_F178_EN_US_20_2K_20220926_AutoDCP_SMPTE_OV" in meantime between first and second calls you described? Such an error usually means the source can't be found.

[Greg-DB]

@brian q. As Здравко, please check the source is still available at the time of the save call, as that would be typical cause of an error like that. Otherwise, feel free to open an API ticket with some additional details if you'd like us to look into it specifically. In particular, the account IDs for the source account and the receiving account as well as several sample 'X-Dropbox-Request-Id' response header values for a few of these failures would likely be useful in this case.

[quandt]

So how many years later, finally got an answer to this odd behavior.

In short, the issue for "not found" does not really give you much to go on.   Specially when you know the files exist (cuz your own code put it there in the test).   The problem was/is the user account.   Accounts can have their 'sharing' feature disabled due to whatever reasons, unfofrtunately the API just gets a NOT_FOUND type message, with no further information, the web hooks seem to have access to more info, maybe the api's do as well or maybe there's an additional info lookup on such things, but for now I'm saying this 'bug' is resolved.