You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
2/files/get_metadata 409 path/not_found
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
Dropbox Staff
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.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-DBI 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).
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.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
