Test that ClusterInfo is refreshed when a new node is added
#134101
Conversation
nicktindall
added
>test
elasticsearchmachine
added
Team:Distributed Coordination
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
| ); | ||
| // Don't use runUntilFlag because we don't want the scheduled task to run | ||
| deterministicTaskQueue.runAllRunnableTasks(); | ||
| assertTrue(nodeJoined.get()); |
There was a problem hiding this comment.
this may be why the existing tests don't assert anything, it feels a little hacky, but this seemed like the right test to add to? Could also implement as an IT
There was a problem hiding this comment.
Pull Request Overview
This PR adds a test to verify that the ClusterInfo is refreshed when a new node joins the cluster, addressing a gap in test coverage for this critical behavior. The test ensures that when nodes are added to a cluster, the InternalClusterInfoService eagerly fetches updated cluster information, which is important for proper shard allocation decisions.
Key changes:
- Added test coverage for node join and leave scenarios in cluster info service scheduling
- Verified that cluster info refresh is triggered when nodes join but not when they leave
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
server/src/test/java/org/elasticsearch/cluster/InternalClusterInfoServiceSchedulingTests.java
Outdated
Show resolved
Hide resolved
…InfoServiceSchedulingTests.java Co-authored-by: Copilot <[email protected]>
3 participants
As an alternative to adding code to model shard movements to/from nodes with no
NodeUsageStatsForThreadPoolsin the currentClusterInfo, just add a test to confirm that the situation is only very brief, because we eagerly fetch a newClusterInfowhen that occurs.There didn't seem to be a test that covered this behaviour specifically (it dates back to the dark ages). Interesting that many of the other scenarios (
become master 1,fail master 1,become master 2,fail master 2) don't seem to assert that theInternalClusterInfoServiceactually did anything? You can comment out all the behaviour inorg.elasticsearch.cluster.InternalClusterInfoService#clusterChangedand the only bit that fails is the interval polling part.I can add assertions to those if we think it's worthwhile?