2/files/get_metadata 409 path/not_found

[Info V.1]

We have been seeing the following 409 error recently on multiple customers where get_metadata fails with 409 path/not found. But later when diagnosing the problem the same call works fine. Is there a possibility that this API call fail soon(like couple of minutes) after the file uploaded.

curl -X POST \
  https://api.dropboxapi.com/2/files/get_metadata \
  -H 'authorization: Bearer <Redacted>' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -H 'dropbox-api-select-user: dbmid:AAA8Po3CW3EaZ70sT3HalBKsIgTG91nKmgI' \
  -d '{
      "path": "id:YKwssHaJWqAAAAAAAAAtKw",
      "include_has_explicit_shared_members": true,
      "include_deleted": true
}'

Failure response

HTTP/1.1 409 Conflict

responseBody='{"error_summary": "path/not_found/...", "error": {".tag": "path", "path": {".tag": "not_found"}}}',

respHeaders=[
Server: nginx, Date: Fri, 06 Apr 2018 15:21:42 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Content-Security-Policy: sandbox; frame-ancestors 'none'
X-Dropbox-Request-Id: b04b42db9cead7dd8f2fc966e0d63ab3
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename='error'
]

Success response body,

{
    ".tag": "file",
    "name": "**redacted**",
    "path_lower": "**redacted**",
    "path_display": "**redacted**",
    "parent_shared_folder_id": "2830010752",
    "id": "id:YKwssHaJWqAAAAAAAAAtKw",
    "client_modified": "2016-08-19T00:05:39Z",
    "server_modified": "2018-04-06T14:42:39Z",
    "rev": "1d55a8ae8980",
    "size": 1475,
    "sharing_info": {
        "read_only": false,
        "parent_shared_folder_id": "2830010752",
        "modified_by": "dbid:AAAHCnrxGJ80Wp57W0bGPk5jG9iQKCLHxOI"
    },
    "has_explicit_shared_members": false,
    "content_hash": "b5150c9c0885975187a3a3a80c4ae63c94b52cf8a51ecca702220472753e48cf"
}

[Greg-DB]

Thanks for the report! There shouldn't be a delay for getting file metadata like this after a file is uploaded.

I just looked into this, and as far as I can tell, that error was correct at that time. I can't disclose private account information of course, but it is possible for users to gain/lose access to files or folders over time, which would explain changing API results.

For example, a user can add or remove (or be added or removed from) a shared folder at any point in time, which would change whether or not they have access to that file's metadata.

[Info V.1]

We have had multiple instances of this, where for eg. in a Team folder on which a Group had access, a user who was always part of this group uploads a file, we get the event and the fileId, and we try to run get_metadata on the file Id, with as-user as the same user, it was failing with 409 path not found. 

What information would you need the next time we run into the same issue?

[Greg-DB]

I just double checked this, and again there doesn't seem to have been an issue here. It's important to keep in mind that users/shared folder owners can move around content, and change permissions, at any point in time. It's also possible for any particular user to not actually be a member of a team folder (or of a group with access to a team folder).

For example, a user can upload a file in a shared folder, and then someone else move that file to a different shared folder that the user doesn't have access to (yet, perhaps).

[Inderjeetdev]

I noticed a file name used in code was deleted on Dropbox, so its details couldn't be fetched in code, which triggered this 409 error.