Possible race condition when creating in a folder in Team Spaces

[Sam S.6]

When creating a top-level folder with the `files/create_folder` endpoint with a user account with Team Spaces, the folder appears to be created as a personal folder first and then converted and remounted as a shared folder in the root namespace (depending on the team settings). This can lead to strange error messages when attempting to make API calls that create or upload any children to this folder.

The below example discusses the behaviour when attempting to create two folders `/parent` and `/parent/child` successively with `files/create_folder` calls. Depending on the timing of the second API call, I've so far seen four different outcomes (sorted by increasing delay):

1. The child is created immediately after creating the top-level parent, before remounting. This succeeds without errors.
2. The child is created during remounting. This can cause a WriteError (conflict) when attempting to create the parent directory. This looks like a race condition to me: the parent directory temporarily does not exist, the Dropbox backend therefore attempts to create it and then raises a conflict because it has been remounted in the meantime.
3. The child is created immediately after remounting. This causes a WriteError (no_write_permission) if the shared folder does not yet have correctly set permissions.
4. The child is created with a larger delay. It is properly created in the now remounted shared folder.

Is there any recommendation for how to handle creating such nested structures in Team Spaces using the regular user endpoints from a non-admin account? And how much of the above is just expected behaviour that API clients just need to deal with?

[Sam S.6]

As an addendum, the same behaviour can be verified when retrieving the metadata for the `/parent` folder with `files/get_metadata` just after creation:

1. First, metadata for a personal folder is returned.

2. After a short delay, a LookupError is raised.

3. Finally, metadata with correct sharing info is returned.

Maybe creating folders in the Team Space should be done using the `sharing/share_folder` endpoint instead to avoid this unmounting and mounting? Alternatively, the Dropbox API could wait before returning from `/files/create_folder` until the folder is "properly" set up.

[Greg-DB]

Thanks for the detailed write-up! Yes, as you found, the Dropbox backend needs to perform some additional work immediately after a folder like this is created. There isn't a great way to check on this programmatically unfortunately, so please add a sufficient delay. I know this is non-ideal and can be slow, so I'll send this along as feedback to the team to see if we can improve or eliminate this in the future. Apologies for the bother!

[Sam S.6]

Ok, thanks for passing this on. I am using she `sharing/share_folder` endpoint for now when creating a folder in a Team Space. It's not ideal for creating folders because the error and conflict handling is geared towards sharing existing folders and is not particularly helpful in case of malformed paths and other "WriteError" scenarios. This endpoint does however create a Team Space folder "atomically", without unmounting and mounting or changing permissions. It's also slow, sometimes up to 25 sec to create a shared folder, but I've seen similar delays when waiting for the entire remounting process to complete.