[CI] TimeSeriesDataStreamsIT testSearchableSnapshotAction failing #125867
Assignees
Labels
:Data Management/ILM+SLM
Index and Snapshot lifecycle management
low-risk
An open issue or test failure that is a low risk to future releases
Team:Data Management
Meta label for data/management team
>test-failure
Triaged test failures from CI
Comments
elasticsearchmachine
added
:Data Management/ILM+SLM
|
This has been muted on branch main Mute Reasons:
Build Scans: |
elasticsearchmachine
added a commit
that referenced
this issue
Mar 28, 2025
elasticsearchmachine
added
Team:Data Management
|
Pinging @elastic/es-data-management (Team:Data Management) |
nielsbauman
added
low-risk
|
I already encountered this over at #125752 (comment). It's caused by ILM being stuck in the wait-for-index-color step. We're currently still discussing the best way to tackle this issue - I opened #125812 for a different test class but we're discussing if we want to go for a different approach. |
omricohenn
pushed a commit
to omricohenn/elasticsearch
that referenced
this issue
Mar 28, 2025
This was referenced Mar 31, 2025
nielsbauman
added a commit
that referenced
this issue
Apr 1, 2025
ILM sometimes skips a policy/index for a cluster state update if the step was still running/enqueued while the update came in. That on its own isn't a problem, but in very quiet clusters, this would mean that it could take arbitrarily long for the policy step to be run - i.e. when the next cluster state comes in. We saw this happening in a few tests, but it could potentially happen in production too. Fixes #125683 Fixes #125789 Fixes #125867 Fixes #125911
nielsbauman
added a commit
that referenced
this issue
Apr 1, 2025
ILM sometimes skips a policy/index for a cluster state update if the step was still running/enqueued while the update came in. That on its own isn't a problem, but in very quiet clusters, this would mean that it could take arbitrarily long for the policy step to be run - i.e. when the next cluster state comes in. We saw this happening in a few tests, but it could potentially happen in production too. Fixes #125683 Fixes #125789 Fixes #125867 Fixes #125911
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this issue
Apr 1, 2025
ILM sometimes skips a policy/index for a cluster state update if the step was still running/enqueued while the update came in. That on its own isn't a problem, but in very quiet clusters, this would mean that it could take arbitrarily long for the policy step to be run - i.e. when the next cluster state comes in. We saw this happening in a few tests, but it could potentially happen in production too. Fixes elastic#125683 Fixes elastic#125789 Fixes elastic#125867 Fixes elastic#125911 Fixes elastic#126053
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this issue
Apr 1, 2025
ILM sometimes skips a policy/index for a cluster state update if the step is still running/enqueued when the update comes in. That on its own isn't a problem, but in very quiet clusters, this would mean that it could take arbitrarily long for the policy step to be run - i.e. when the next cluster state comes in. We saw this happening in a few tests, but it could potentially happen in production too. Fixes elastic#125683 Fixes elastic#125789 Fixes elastic#125867 Fixes elastic#125911 Fixes elastic#126053
This was referenced Apr 1, 2025
nielsbauman
added a commit
that referenced
this issue
Apr 10, 2025
The `indexNameSupplier` was included in the equality and is of type `BiFunction`, which doesn't implement a proper `equals` method by default - and thus neither do the lambdas. This meant that two instances of this step would only be considered equal if they were the same instance. By excluding `indexNameSupplier` from the `equals` method, we ensure the method works as intended and is able to properly tell the equality between two instances. As a side effect, we expect/hope this change will fix a number of tests that were failing because `WaitForIndexColorStep` missed the last cluster state update in the test, causing ILM to get stuck and the test to time out. Fixes #125683 Fixes #125789 Fixes #125867 Fixes #125911 Fixes #126053 Fixes #126354
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this issue
Apr 10, 2025
The `indexNameSupplier` was included in the equality and is of type `BiFunction`, which doesn't implement a proper `equals` method by default - and thus neither do the lambdas. This meant that two instances of this step would only be considered equal if they were the same instance. By excluding `indexNameSupplier` from the `equals` method, we ensure the method works as intended and is able to properly tell the equality between two instances. As a side effect, we expect/hope this change will fix a number of tests that were failing because `WaitForIndexColorStep` missed the last cluster state update in the test, causing ILM to get stuck and the test to time out. Fixes elastic#125683 Fixes elastic#125789 Fixes elastic#125867 Fixes elastic#125911 Fixes elastic#126053 Fixes elastic#126354
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this issue
Apr 10, 2025
The `indexNameSupplier` was included in the equality and is of type `BiFunction`, which doesn't implement a proper `equals` method by default - and thus neither do the lambdas. This meant that two instances of this step would only be considered equal if they were the same instance. By excluding `indexNameSupplier` from the `equals` method, we ensure the method works as intended and is able to properly tell the equality between two instances. As a side effect, we expect/hope this change will fix a number of tests that were failing because `WaitForIndexColorStep` missed the last cluster state update in the test, causing ILM to get stuck and the test to time out. Fixes elastic#125683 Fixes elastic#125789 Fixes elastic#125867 Fixes elastic#125911 Fixes elastic#126053 Fixes elastic#126354 (cherry picked from commit 3231eb2) # Conflicts: # muted-tests.yml
elasticsearchmachine
pushed a commit
that referenced
this issue
Apr 10, 2025
The `indexNameSupplier` was included in the equality and is of type `BiFunction`, which doesn't implement a proper `equals` method by default - and thus neither do the lambdas. This meant that two instances of this step would only be considered equal if they were the same instance. By excluding `indexNameSupplier` from the `equals` method, we ensure the method works as intended and is able to properly tell the equality between two instances. As a side effect, we expect/hope this change will fix a number of tests that were failing because `WaitForIndexColorStep` missed the last cluster state update in the test, causing ILM to get stuck and the test to time out. Fixes #125683 Fixes #125789 Fixes #125867 Fixes #125911 Fixes #126053 Fixes #126354 (cherry picked from commit 3231eb2) # Conflicts: # muted-tests.yml
elasticsearchmachine
pushed a commit
that referenced
this issue
Apr 10, 2025
The `indexNameSupplier` was included in the equality and is of type `BiFunction`, which doesn't implement a proper `equals` method by default - and thus neither do the lambdas. This meant that two instances of this step would only be considered equal if they were the same instance. By excluding `indexNameSupplier` from the `equals` method, we ensure the method works as intended and is able to properly tell the equality between two instances. As a side effect, we expect/hope this change will fix a number of tests that were failing because `WaitForIndexColorStep` missed the last cluster state update in the test, causing ILM to get stuck and the test to time out. Fixes #125683 Fixes #125789 Fixes #125867 Fixes #125911 Fixes #126053 Fixes #126354 (cherry picked from commit 3231eb2) # Conflicts: # muted-tests.yml # x-pack/plugin/ilm/qa/multi-node/src/javaRestTest/java/org/elasticsearch/xpack/ilm/actions/SearchableSnapshotActionIT.java
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Build Scans:
Reproduction Line:
Applicable branches:
main
Reproduces locally?:
N/A
Failure History:
See dashboard
Failure Message:
Issue Reasons:
Note:
This issue was created using new test triage automation. Please report issues or feedback to es-delivery.
The text was updated successfully, but these errors were encountered: