Only validate primary ids on release branches #135044
Merged
Conversation
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
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
rjernst
added
:Core/Infra/Core
elasticsearchmachine
added
v9.2.0
Team:Core/Infra
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
mark-vieira
approved these changes
Sep 18, 2025
| TransportVersionUpperBound currentUpperBound = upperBounds.get(currentUpperBoundName); | ||
|
|
||
| // non-main branches | ||
| for (TransportVersionUpperBound upperBound : upperBounds.values()) { |
There was a problem hiding this comment.
nit: FWIW, I like using streams here for stuff like this. For example:
return upperBounds.values().stream()
.anyMatch(u -> u.definitionId().complete() > currentUpperBound.definitionId().complete())
elasticsearchmachine
added
the
serverless-linked
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Sep 19, 2025
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Sep 19, 2025
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Sep 19, 2025
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Sep 19, 2025
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Sep 19, 2025
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Sep 19, 2025
* Add more transport version validation cases (#134597) This commit adds a few more validations: * we cannot jump the primary id more than the normal increment * we cannot remove an existing id Also fixed definition path output in some validation error messages. * Only validate primary ids on release branches (#135044) Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound. * fix compile
elasticsearchmachine
pushed a commit
that referenced
this pull request
Sep 19, 2025
* Add more transport version validation cases (#134597) This commit adds a few more validations: * we cannot jump the primary id more than the normal increment * we cannot remove an existing id Also fixed definition path output in some validation error messages. * Only validate primary ids on release branches (#135044) Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound. * fix compile
szybia
added a commit
to szybia/elasticsearch
that referenced
this pull request
Sep 19, 2025
* upstream/main: Turn NumericValues into functional interface (elastic#135068) Improve block loader for source only runtime fields of type keyword (elastic#135026) Mute org.elasticsearch.xpack.esql.qa.single_node.EsqlSpecIT test {csv-spec:stats.StdDeviationGroupedAllTypes} elastic#135103 Mute org.elasticsearch.xpack.esql.qa.single_node.EsqlSpecIT test {csv-spec:stats.StdDeviationWithLongs} elastic#135102 Mute org.elasticsearch.xpack.esql.qa.single_node.EsqlSpecIT test {csv-spec:inlinestats.StdDevFilter} elastic#135101 Mute org.elasticsearch.xpack.esql.qa.single_node.EsqlSpecIT test {csv-spec:stats.StdDevFilter} elastic#135100 Remove track_live_docs_in_memory_bytes feature flag (elastic#134900) Create SPI to allow prohibiting certain top-level mappings (elastic#132360) Only validate primary ids on release branches (elastic#135044) Added no-op support for project_routing query param to REST endpoints that will support cross-project search (elastic#134741) Fix race in FileSettingsServiceIT.testSettingsAppliedOnStart (elastic#134368)
elasticsearchmachine
pushed a commit
that referenced
this pull request
Sep 23, 2025
* Add more transport version validation cases (#134597) This commit adds a few more validations: * we cannot jump the primary id more than the normal increment * we cannot remove an existing id Also fixed definition path output in some validation error messages. * Only validate primary ids on release branches (#135044) Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported. This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we _might_ be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Primary ids are only incremented on the main branch. For release branches only patch ids will be created. The primary id validation won't always work on release branches because only some of the primary ids will be backported.
This commit skips primary id validation if we are sure we are on a release branch. We can tell this by looking at the current upper bound compared to other upper bounds. If there is a newer one, we know we are on a release branch. If there isn't a newer one, we might be on a release branch, or on main, but in this case doing primary id validation is ok because there's effectively no difference, we are looking at the latest upper bound.