-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
[9.0] Re-remove min compatible version from SearchRequest (#123859) #125093
Conversation
Re-apply transport changes from elastic#114713 (cherry picked from commit 30a37c3) # Conflicts: # server/src/main/java/org/elasticsearch/TransportVersions.java
blocked by #125095 |
|| in.getTransportVersion().onOrAfter(TransportVersions.REVERT_REMOVE_MIN_COMPATIBLE_SHARD_NODE)) && in.readBoolean()) { | ||
@UpdateForV9(owner = UpdateForV9.Owner.CORE_INFRA) // this can be removed (again) when the v9 transport version can diverge | ||
Version v = Version.readVersion(in); // and drop on the floor | ||
if (in.getTransportVersion().before(TransportVersions.RE_REMOVE_MIN_COMPATIBLE_SHARD_NODE_90) && in.readBoolean()) { |
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.
Maybe I am overthinking this, but shouldn't this be more complex?
IF 9.0 can talk with a ES version that is on a version with REVERT_REMOVE_MIN_COMPATIBLE_SHARD_NODE (8.18, unless this is backported to 8.18 too), it needs to take this branch.
So it could be (
before(REMOVE_MIN_COMPATIBLE_SHARD_NODE)
OR
(onOrAfter(REVERT_REMOVE_MIN_COMPATIBLE_SHARD_NODE) && before(RE_REMOVE_MIN_COMPATIBLE_SHARD_NODE_90))?
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.
The "old behaviour" is before we removed min compatible, or after we reverted it but before we re-removed it
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.
I don't think so. The initial remove was immediately reverted before 8.17.3 and never released (except for maybe serverless), from a 9 perspective before RE_REMOVE_MIN_COMPATIBLE_SHARD_NODE_90
the version always existed in the binary protocol.
public static final TransportVersion INITIAL_ELASTICSEARCH_8_16_6 = def(8_772_0_06);
public static final TransportVersion REMOVE_MIN_COMPATIBLE_SHARD_NODE = def(8_773_0_00);
public static final TransportVersion REVERT_REMOVE_MIN_COMPATIBLE_SHARD_NODE = def(8_774_0_00)
public static final TransportVersion INITIAL_ELASTICSEARCH_8_17_3 = def(8_797_0_03);
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.
The initial remove was immediately reverted before 8.17.3 and never released
Oh I missed that. It makes sense, thank you for checking!
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
|| in.getTransportVersion().onOrAfter(TransportVersions.REVERT_REMOVE_MIN_COMPATIBLE_SHARD_NODE)) && in.readBoolean()) { | ||
@UpdateForV9(owner = UpdateForV9.Owner.CORE_INFRA) // this can be removed (again) when the v9 transport version can diverge | ||
Version v = Version.readVersion(in); // and drop on the floor | ||
if (in.getTransportVersion().before(TransportVersions.RE_REMOVE_MIN_COMPATIBLE_SHARD_NODE_90) && in.readBoolean()) { |
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.
The initial remove was immediately reverted before 8.17.3 and never released
Oh I missed that. It makes sense, thank you for checking!
Backport
This will backport the following commits from
main
to9.0
:Questions ?
Please refer to the Backport tool documentation