Error while creating folder after deleting it from gdrive about flysystem-google-drive-ext HOT 6 CLOSED

@gcilinskas
As @erikn69 pointed out, extensive object caching breaks concurrency. The code of this adapter assumes that it's operating alone on a selected drive.
One way to partially work around this would be to disable all caching in the code (which would slow everything down considerably)...but that's only half of the fix - there's still the issue of mixing write, read, delete, create operations and you'd still have race conditions to solve.
Perhaps you can just change the approach and not work on the same folder from multiple threads/jobs/queues? Or just not delete the folder after you're done with it (I assume you use one job to fill the folder and another to consume what's in it and then delete the folder)?

from flysystem-google-drive-ext.

Yeah, manual human interaction with gdrive is possible on our side so removal of folders might be at random times. We are fetching data from api and saving its assets to gdrive in structured folders hierarchy.

clearCache method helped for now, performance for gdrive upload is not crucial for us. Regarding to racing conditions we did some workarounds with sleep functions, currently seems to work

We don't have options to change approaches in usage of gdrive folders

from flysystem-google-drive-ext.

Ok. So I guess you're doing something similar to:

lRetry:
try {
  ... small set of operations on the drive or a complete set with error mitigation
} catch(\Throwable $e) {
  sleep(rand()%4);
  $adapter->clearCache();
  if($retry-->0)
     goto lRetry;
}

from flysystem-google-drive-ext.

This package is using a little cache trick, if you delete a folder in Google drive manually, that folder still remains in cache even though it no longer exists in google drive (if you are using a long running script, because on every new instance it starts the connection and cache), maybe the function Storage::disk('google')->getDriver()->getAdapter()->clearCache(); before createDir will be useful to you (maybe with catch, only when there is these exception).

from flysystem-google-drive-ext.

Storage::disk('google')->getDriver()->getAdapter()->clearCache();
This one helped, thanks!
Just for information, Since I use queued jobs, I had to call this clearCache command not only once before creating directories, but also in every job class that was using google drive upload

from flysystem-google-drive-ext.

On limitation's section

Using display paths as identifiers for folders and files requires them to be unique. Unfortunately Google Drive allows users to create files and folders with same (displayed) names. In such cases when unique path cannot be determined this adapter chooses the oldest (first) instance

Concurrent use of same Google Drive might lead to unexpected problems due to heavy caching of file/folder identifiers and file objects.

So, for concurrent threads of queued jobs you have to do this workaround with cache, otherwise you get those errors, or when create a directory duplicate(created at the same time with same name) and you put a unique file or folder inside, the adapter will be able to reach it properly because it chooses the oldest (first), so, create directory, uncache the folder, then put file inside
I make a PR with uncacheFolder function, if it is merged it be available on the next release

$disk=\Storage::disk('google');    
$disk->createDir('test/testa');
//manually delete without adapter or other job create it first 
$dir=$disk->getDriver()->getAdapter()->getMetadata('test/testa');
$disk->getDriver()->getAdapter()->getService()->files->delete($dir['id']); 
//uncache
$disk->getDriver()->getAdapter()->uncacheFolder('test/testa'); 
// refresh id and put file
$disk->put('test/testa/file.txt', 'Contents1'); 

from flysystem-google-drive-ext.