-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
SnapshotLifecycleRestIT testFullPolicySnapshot failure #50358
Comments
Pinging @elastic/es-core-features (:Core/Features/ILM+SLM) |
A handful of similar failures: https://gradle-enterprise.elastic.co/s/scv4m7g4w7kcs Muted on master in ae90f8a |
We have another failure in 7.x (CI link, build scan): The symptoms look a bit different to me though:
reproduction line:
Does not reproduce locally. |
This test failed a couple of different ways, related to timing, as well as concurrent snapshots, and also naming. This commit splits the giant `assertBusy` into separate parts so that we don't perform ~5 different requests and tests in the same loop. It also gives each test a unique repository so that no other test can accidentally re-use snapshots. Resolves elastic#50358 (hopefully!)
…51013) This test failed a couple of different ways, related to timing, as well as concurrent snapshots, and also naming. This commit splits the giant `assertBusy` into separate parts so that we don't perform ~5 different requests and tests in the same loop. It also gives each test a unique repository so that no other test can accidentally re-use snapshots. Resolves #50358 (hopefully!)
…lastic#51013) This test failed a couple of different ways, related to timing, as well as concurrent snapshots, and also naming. This commit splits the giant `assertBusy` into separate parts so that we don't perform ~5 different requests and tests in the same loop. It also gives each test a unique repository so that no other test can accidentally re-use snapshots. Resolves elastic#50358 (hopefully!)
This test failed a couple of different ways, related to timing, as well as concurrent snapshots, and also naming. This commit splits the giant `assertBusy` into separate parts so that we don't perform ~5 different requests and tests in the same loop. It also gives each test a unique repository so that no other test can accidentally re-use snapshots. Resolves #50358 (hopefully!)
Sorry, I have to re-open:
from |
…tic#51055) This test failed a couple of different ways, related to timing, as well as concurrent snapshots, and also naming. This commit splits the giant `assertBusy` into separate parts so that we don't perform ~5 different requests and tests in the same loop. It also gives each test a unique repository so that no other test can accidentally re-use snapshots. Resolves elastic#50358 (hopefully!)
Rather than check the first returned snapshot for a snapshot starting with `snap-` in SnapshotLifecycleRestIT.testFullPolicy, this commit changes the test to find any snapshots starting with `snap-`. In the event that there are no snapshots (the failure case), this also exposes the full results map so we can diagnose why a failure occurred. Relates to elastic#50358
* Check all snapshots in SnapshotLifecycleRestIT.testFullPolicy Rather than check the first returned snapshot for a snapshot starting with `snap-` in SnapshotLifecycleRestIT.testFullPolicy, this commit changes the test to find any snapshots starting with `snap-`. In the event that there are no snapshots (the failure case), this also exposes the full results map so we can diagnose why a failure occurred. Relates to #50358 * Use a more imperative style for checking
…c#51386) * Check all snapshots in SnapshotLifecycleRestIT.testFullPolicy Rather than check the first returned snapshot for a snapshot starting with `snap-` in SnapshotLifecycleRestIT.testFullPolicy, this commit changes the test to find any snapshots starting with `snap-`. In the event that there are no snapshots (the failure case), this also exposes the full results map so we can diagnose why a failure occurred. Relates to elastic#50358 * Use a more imperative style for checking
* Check all snapshots in SnapshotLifecycleRestIT.testFullPolicy Rather than check the first returned snapshot for a snapshot starting with `snap-` in SnapshotLifecycleRestIT.testFullPolicy, this commit changes the test to find any snapshots starting with `snap-`. In the event that there are no snapshots (the failure case), this also exposes the full results map so we can diagnose why a failure occurred. Relates to #50358 * Use a more imperative style for checking
It's now failing in a different way, but immediately after the code that was changed in #51386 to try and fix this:
That is coming from line 123 of
This has happened a few times on the 7.x branch. A couple of examples are:
A repro command is:
This didn't reproduce locally for me. |
This previously was missing some key information in the output of the failure. This captures that information and adds logging at each step so we can determine the cause *if* it fails again. Resolves elastic#50358
* Fix SnapshotLifecycleRestIT.testFullPolicySnapshot This previously was missing some key information in the output of the failure. This captures that information and adds logging at each step so we can determine the cause *if* it fails again. Resolves #50358
* Fix SnapshotLifecycleRestIT.testFullPolicySnapshot This previously was missing some key information in the output of the failure. This captures that information and adds logging at each step so we can determine the cause *if* it fails again. Resolves elastic#50358
* Fix SnapshotLifecycleRestIT.testFullPolicySnapshot This previously was missing some key information in the output of the failure. This captures that information and adds logging at each step so we can determine the cause *if* it fails again. Resolves #50358
It came back 😱
https://gradle-enterprise.elastic.co/s/l3ntz5zhjvxry/tests/ao2nxxbijves6-3ndcchqutszas
|
Muted on master in 340fcd1 |
This failure on 7.7 looks similar.
https://gradle-enterprise.elastic.co/s/dfi2xbqejo4fu Looks like it still fails on 7.x and 7.7 around 3-4 times a month. @dakrone should we mute those branches as well or are you looking for more infos? |
I believe this should be resolved now that #56911 has been merged, so I'm going to close it, we can re-open if it occurs again. |
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+multijob-windows-compatibility/os=windows-2016/331/console
https://gradle-enterprise.elastic.co/s/fmz3orwsf6ceu
Does not reproduce:
The text was updated successfully, but these errors were encountered: