Skip to content

Improve ShardRoutingState docs #126875

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

DiannaHohensee
Copy link
Contributor

@DiannaHohensee DiannaHohensee commented Apr 15, 2025

@DaveCTurner Improving the class docs in reference to this comment thread.

I want to reference it in the other PR, so I'm committing it separately.

@DiannaHohensee DiannaHohensee added >non-issue :Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) Team:Distributed Coordination Meta label for Distributed Coordination team labels Apr 15, 2025
@DiannaHohensee DiannaHohensee self-assigned this Apr 15, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a few tiny comments

* The shard is not assigned to any node; any data which it contains is unavailable to the cluster.
*
* A shard transitions from {@link #UNASSIGNED} to {@link #INITIALIZING} when the master wants an assigned data node to create or start
* recovering this shard copy. A shard may also transition back to {@link #UNASSIGNED} in case of an assignment failure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really any failure puts it back to UNASSIGNED - the phrase "assignment failure" indicates to me a problem in allocation (the process which assigns shards to nodes) but in fact most unassignments will be due to other failures.

Suggested change
* recovering this shard copy. A shard may also transition back to {@link #UNASSIGNED} in case of an assignment failure.
* recovering this shard copy. A shard may also transition back to {@link #UNASSIGNED} in case of a failure.

Comment on lines +25 to +26
* The shard is assigned to a node and the recovery process has begun. The shard data is not yet available on the node initializing the
* shard.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny nitpick: if the shard is in IndexShardState#POST_RECOVERY then it can respond to searches even before it's moved to ShardRoutingState#STARTED in the cluster state.

DiannaHohensee and others added 2 commits April 16, 2025 12:29
…utingState.java

Co-authored-by: David Turner <david.turner@elastic.co>
…utingState.java

Co-authored-by: David Turner <david.turner@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >non-issue Team:Distributed Coordination Meta label for Distributed Coordination team v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants