-
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
Always delegate TransportIndexAction and TransportDeleteAction to bulk action #40424
Conversation
Pinging @elastic/es-distributed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for picking this up.
@@ -166,6 +166,7 @@ protected void registerRequestHandlers(String actionName, TransportService trans | |||
|
|||
@Override | |||
protected void doExecute(Task task, Request request, ActionListener<Response> listener) { | |||
assert request.shardId() != null : "request shardId must be set"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting - did you run into a situation when this wasn't the case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, but this work got triggered by looking at open Github issues, in particular #20279 . In particular I noticed that the desired property to have a complete ShardId when replication requests get to the reroute phase already holds today.
This PR does not close that issue out (needs further investigation on what exactly needs to be done), but addresses the first point on it.
@elasticmachine run elasticsearch-ci/packaging-sample |
The implementation of TransportIndexAction and TransportDeleteAction as TransportReplicationAction existed for interoperability with older 5.x nodes, as these older nodes coordinated single index / deletes as replication requests. This BWC layer is no longer needed in 7.x, where these single actions are now mapped to bulk requests. Completely removing the deprecated transport actions is not possible yet if we want to keep BWC with a 6.x transport client. The best way here is to wait for the transport client to go away and then just remove the actions.
The implementation of
TransportIndexAction
andTransportDeleteAction
asTransportReplicationAction
existed for interoperability with older 5.x nodes, as these older nodes coordinated single index / deletes as replication requests. This BWC layer is no longer needed in 7.x, where these single actions are now mapped to bulk requests. Completely removing the deprecated transport actions is not possible yet if we want to keep BWC with a 6.x transport client. The best way here is to wait for the transport client to go away and then just remove the actions.