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.
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?
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).
We love to learn from the educators who use Dropbox. Whether you teach kids, teens, adults or a combination of all three, we want to know what apps and integrations you use with Dropbox to help with teaching. Which of the ones below is your favorite, or most used tool?