ESQL: Add createdVersion for types#137432
Merged
craigtaverner merged 9 commits intoelastic:mainfrom Dec 5, 2025
Merged
Conversation
alex-spies
added
>test
Collaborator
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
elasticsearchmachine
added
the
Team:Analytics
This was referenced Nov 6, 2025
nik9000
approved these changes
Nov 7, 2025
Member
nik9000
left a comment
nik9000
left a comment
There was a problem hiding this comment.
Makes sense to me and should make our situation better.
idegtiarenko
approved these changes
Nov 10, 2025
Contributor
Author
|
Will update and merge after #137431. |
alex-spies
added
the
auto-backport
alex-spies
added
the
auto-merge-without-approval
Contributor
Author
|
Unrelated release test failure: #138946 Let's get these muted; at least the serverless checks better be passing. (The only release tests that matter are the AllFieldsSupportedITs, and they're fine.) |
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
craigtaverner
added a commit
to craigtaverner/elasticsearch
that referenced
this pull request
Dec 5, 2025
* Add createdVersion for types * [CI] Update transport version definitions * [CI] Update transport version definitions * Do not create new transport version for exp histo --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co> Co-authored-by: Craig Taverner <craig@amanzi.com>
Contributor
|
Manual backport to 9.2 in #139098 |
craigtaverner
added a commit
that referenced
this pull request
Dec 5, 2025
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 9, 2025
#137432 added a minimum transport version to data types that are *under construction*, so that even in SNAPSHOT builds a coordinator node can decide whether other nodes or clusters are new enough to understand a data type that recently became supported in ESQL. The `EXPONENTIAL_HISTOGRAM` type is one such type that is currently under construction. #137432 wrongly gave it a minimum transport version that was also backported to 9.2, even though the type is exclusive to 9.3 so far (even in SNAPSHOT builds). To keep things consistent, use a newer minimum transport version for `EXPONENTIAL_HISTOGRAM`, namely the first version after it was added which was also not backported to 9.2. (There wasn't any breakage from this because we don't have tests that do anything with `EXPONENTIAL_HISTOGRAM` in mixed 9.2/9.3 clusters/CCS to my knowledge.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a new type is added, it is marked as under construction and considered always supported when running tests on SNAPSHOT builds.
This is problematic for existing ENRICH tests because they correctly use
DATE_RANGEfields, which we are trying to add support to. When turningDATE_RANGEfrom unsupported to under construction, our bwc tests break because old nodes, of course, can't even deserialize the newDATE_RANGEdata type.Add the notion of a
createdVersionfor new data types. This is the first version from which the type can be used in SNAPSHOT builds and tests; for released types, this version is additional (and generally different) to the supported version, which is the first version on which production builds will consider a type as supported.