You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For local filesystems, it will work fine, but for example s3 it is undesired order of actions:
S3 guarantees consistency for newly created objects.
But for deletes and overwrites with PUT, it doesn't guarantee it. (I don't remember the actual timings).
As a result, we can get into a situation with consequential checks - in the previous one we just deleted an object, in current we add a new object with the same name and it actually considered as overriding, so now it is possible to get file not found exception during an attempt to get content from that file (new version hasn't propagated yet to replace deleted one).
Please note, that the delete action is not a key here - it is similar to PUT request.
So, this checker is inappropriate for S3 with short grace.
Possible workaround:
Force to not using constant strings as the file name
Add some small hash (maybe 4 letters UUID will be good enough) internally to the value of filename in the checker.
The text was updated successfully, but these errors were encountered:
Given
PragmaRX\Health\Checkers\CloudStorage
:The logic of checker is straightforward:
For local filesystems, it will work fine, but for example s3 it is undesired order of actions:
PUT
, it doesn't guarantee it. (I don't remember the actual timings).So, this checker is inappropriate for S3 with short grace.
Possible workaround:
The text was updated successfully, but these errors were encountered: