-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CI] RepositoryS3ClientYamlTestSuiteIT.test failed to restore snapshot #41882
Comments
Pinging @elastic/es-distributed |
Just for the record: I talked to infra about this one an they don't know of anything special this morning that could've caused this (this is a 3rd party S3 test). => I'm investigating where this could've come from still, doesn't look like it was an outside issue with the S3 bucket. |
* First off, this exists check is somewhat pointless in that it checks for the existence of a blob that contains a UUID in its name so we don't expect collisions here ever. Just checking for no name collision is completely sufficient. * More importantly though, this check introduces an issue on S3 because we will run it against a non existing snap-{uuid}.dat blob! * This leads to the fact that subsequent reads of this blob after it was written can still return a 404 because AWS S3 only guarantees first read after write consistency. If a read of a key is made before a write is made this guarantee goes out the window. (see https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel for more) * Closes elastic#41882
This is an actual bug in our code that together with S3's eventual consistency caused trouble. Fix in #41898 |
* First off, this exists check is somewhat pointless in that it checks for the existence of a blob that contains a UUID in its name so we don't expect collisions here ever. Just checking for no name collision is completely sufficient. * Since this check was the only user of the blob store format method I removed that now dead method * More importantly though, this check introduces an issue on S3 because we will run it against a non existing snap-{uuid}.dat blob * This leads to the fact that subsequent reads of this blob after it was written can still return a 404 because AWS S3 only guarantees first read after write consistency. If a read of a key is made before a write is made this guarantee goes out the window. (see https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel for more) * Closes #41882
* First off, this exists check is somewhat pointless in that it checks for the existence of a blob that contains a UUID in its name so we don't expect collisions here ever. Just checking for no name collision is completely sufficient. * Since this check was the only user of the blob store format method I removed that now dead method * More importantly though, this check introduces an issue on S3 because we will run it against a non existing snap-{uuid}.dat blob * This leads to the fact that subsequent reads of this blob after it was written can still return a 404 because AWS S3 only guarantees first read after write consistency. If a read of a key is made before a write is made this guarantee goes out the window. (see https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel for more) * Closes elastic#41882
Failed for master: https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+third-party-tests-s3/345/console
Reproduction line
(does not) reproduce locally
Example relevant log:
Frequency
1st failure
The text was updated successfully, but these errors were encountered: