Skip to content

Conversation

rjernst
Copy link
Member

@rjernst rjernst commented Aug 28, 2025

Most upper bounds files for transport version are for an already branched version. For those, the upper bound must be within the base id for that branch, and validation exists to ensure the highest id within a branch is in the upper bound file for that branch. But for main the base is always different. This commit adds validation to ensure that the highest transport version id exists in some upper bound file.

Note that while we could try to identify which upper bound file belongs to main, this is tricky when validation runs in non-main branches. This check is just as good, just a little less specific than "it should exist in x.y upper bound file".

Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
@rjernst rjernst requested a review from a team as a code owner August 28, 2025 00:56
@rjernst rjernst added >non-issue :Core/Infra/Core Core issues without another label auto-backport Automatically create backport pull requests when merged v9.1.4 v9.0.7 v8.18.7 v8.19.4 labels Aug 28, 2025
@rjernst rjernst requested a review from jdconrad August 28, 2025 00:57
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@elasticsearchmachine elasticsearchmachine added Team:Core/Infra Meta label for core/infra team v9.2.0 labels Aug 28, 2025
Copy link
Contributor

@jdconrad jdconrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@rjernst rjernst merged commit 83cd6a1 into elastic:main Aug 28, 2025
34 checks passed
@rjernst rjernst deleted the transport/main_upper_bound_latest branch August 28, 2025 16:35
rjernst added a commit to rjernst/elasticsearch that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
rjernst added a commit to rjernst/elasticsearch that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
rjernst added a commit to rjernst/elasticsearch that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
@elasticsearchmachine
Copy link
Collaborator

💚 Backport successful

Status Branch Result
9.1
9.0
8.18
8.19

rjernst added a commit to rjernst/elasticsearch that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
elasticsearchmachine pushed a commit that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
elasticsearchmachine pushed a commit that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
elasticsearchmachine pushed a commit that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
elasticsearchmachine pushed a commit that referenced this pull request Aug 28, 2025
Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
sarog pushed a commit to portsbuild/elasticsearch that referenced this pull request Sep 11, 2025
…33741)

Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
sarog pushed a commit to portsbuild/elasticsearch that referenced this pull request Sep 19, 2025
…33741)

Most upper bounds files for transport version are for an already
branched version. For those, the upper bound must be within the base id
for that branch, and validation exists to ensure the highest id within a
branch is in the upper bound file for that branch. But for main the base
is always different. This commit adds validation to ensure that the
highest transport version id exists in _some_ upper bound file.

Note that while we could try to identify which upper bound file belongs
to main, this is tricky when validation runs in non-main branches. This
check is just as good, just a little less specific than "it should exist
in x.y upper bound file".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-backport Automatically create backport pull requests when merged :Core/Infra/Core Core issues without another label >non-issue Team:Core/Infra Meta label for core/infra team v8.18.7 v8.19.4 v9.0.7 v9.1.4 v9.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants