-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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] SLMSnapshotBlockingIntegTests.testRetentionWhileSnapshotInProgress failing #47834
Comments
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
This has been failing often enough that I've muted this in |
One of the tests in this suit stops a master node, plus we're doing other node starts in this suit. => the internal test cluster should be TEST and not `SUITE` scoped to avoid random failures like the one in elastic#47834 Closes elastic#47834
Pinging @elastic/es-core-features (:Core/Features/ILM+SLM) |
One of the tests in this suit stops a master node, plus we're doing other node starts in this suit. => the internal test cluster should be TEST and not `SUITE` scoped to avoid random failures like the one in elastic#47834 Closes elastic#47834
The test failed on the intake: https://gradle-enterprise.elastic.co/s/anqtao57gamow
|
This will be trivial to fix now thanks to #48329 , I'm on it :) |
This failed again on master but with HLRC: https://gradle-enterprise.elastic.co/s/5abbkuha6acvy/console-log |
This is intended as a stop-gap solution/improvement to #38941 that prevents repo modifications without an intermittent master failover from causing inconsistent (outdated due to inconsistent listing of index-N blobs) `RepositoryData` to be written. Tracking the latest repository generation will move to the cluster state in a separate pull request. This is intended as a low-risk change to be backported as far as possible and motived by the recently increased chance of #38941 causing trouble via SLM (see #47520). Closes #47834 Closes #49048
This is intended as a stop-gap solution/improvement to elastic#38941 that prevents repo modifications without an intermittent master failover from causing inconsistent (outdated due to inconsistent listing of index-N blobs) `RepositoryData` to be written. Tracking the latest repository generation will move to the cluster state in a separate pull request. This is intended as a low-risk change to be backported as far as possible and motived by the recently increased chance of elastic#38941 causing trouble via SLM (see elastic#47520). Closes elastic#47834 Closes elastic#49048
This is intended as a stop-gap solution/improvement to elastic#38941 that prevents repo modifications without an intermittent master failover from causing inconsistent (outdated due to inconsistent listing of index-N blobs) `RepositoryData` to be written. Tracking the latest repository generation will move to the cluster state in a separate pull request. This is intended as a low-risk change to be backported as far as possible and motived by the recently increased chance of elastic#38941 causing trouble via SLM (see elastic#47520). Closes elastic#47834 Closes elastic#49048
This is intended as a stop-gap solution/improvement to #38941 that prevents repo modifications without an intermittent master failover from causing inconsistent (outdated due to inconsistent listing of index-N blobs) `RepositoryData` to be written. Tracking the latest repository generation will move to the cluster state in a separate pull request. This is intended as a low-risk change to be backported as far as possible and motived by the recently increased chance of #38941 causing trouble via SLM (see #47520). Closes #47834 Closes #49048
This is intended as a stop-gap solution/improvement to #38941 that prevents repo modifications without an intermittent master failover from causing inconsistent (outdated due to inconsistent listing of index-N blobs) `RepositoryData` to be written. Tracking the latest repository generation will move to the cluster state in a separate pull request. This is intended as a low-risk change to be backported as far as possible and motived by the recently increased chance of #38941 causing trouble via SLM (see #47520). Closes #47834 Closes #49048
org.elasticsearch.xpack.slm.SLMSnapshotBlockingIntegTests.testRetentionWhileSnapshotInProgress
has started failing pretty often now with the following error:Here are some example build scans:
https://gradle-enterprise.elastic.co/s/hlldgfw3cx4bc/tests/rfsroxnx4sflo-uvkkyo6qd6mno
https://gradle-enterprise.elastic.co/s/i4ncjbmiflt6a/tests/rfsroxnx4sflo-uvkkyo6qd6mno
https://gradle-enterprise.elastic.co/s/33mp5rqowzsbi/tests/rfsroxnx4sflo-uvkkyo6qd6mno
Looking at build-stats this looks to be happening in both
master
and7.x
.The text was updated successfully, but these errors were encountered: