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.