Skip to content
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

Merged
merged 1 commit into from
Mar 18, 2025

Conversation

mosche
Copy link
Contributor

@mosche mosche commented Mar 18, 2025

Backport

This will backport the following commits from main to 9.0:

Questions ?

Please refer to the Backport tool documentation

Re-apply transport changes from elastic#114713

(cherry picked from commit 30a37c3)

# Conflicts:
#	server/src/main/java/org/elasticsearch/TransportVersions.java
@mosche
Copy link
Contributor Author

mosche commented Mar 18, 2025

blocked by #125095

@mosche mosche added the :Core/Infra/Core Core issues without another label label Mar 18, 2025
@mosche mosche requested review from ldematte and a team March 18, 2025 13:30
|| 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()) {
Copy link
Contributor

@ldematte ldematte Mar 18, 2025

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))?

Copy link
Contributor

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

Copy link
Contributor Author

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);

Copy link
Contributor

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!

Copy link
Contributor

@ldematte ldematte left a 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()) {
Copy link
Contributor

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!

@mosche mosche merged commit 76bd65e into elastic:9.0 Mar 18, 2025
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport :Core/Infra/Core Core issues without another label v9.0.1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants