[fix](be) Restore SNII proto field numbers to the shipped layout - #67135
Open
airborne12 wants to merge 1 commit into
Open
[fix](be) Restore SNII proto field numbers to the shipped layout#67135airborne12 wants to merge 1 commit into
airborne12 wants to merge 1 commit into
Conversation
### What problem does this PR solve? Issue Number: None Related PR: apache#66052 Problem Summary: SNII shipped before its metadata messages reached upstream, and the version upstreamed in apache#66052 had INSERTED fields in the middle of two of them rather than appending. protobuf identifies a field by its tag, so the two layouts now disagree about what a tag means, and every SNII segment already written decodes incorrectly under the upstream numbering: SniiStatsPB shipped upstream (apache#66052) tag 4 null_count sum_total_term_freq tag 5 -- null_count SniiSectionRefsPB shipped upstream (apache#66052) tag 3 null_bitmap norms tag 4 bsbf null_bitmap tag 5 -- bsbf Neither misread fails. SniiStatsPB tags 4 and 5 are both uint64, so a null count is returned as the collection token sum and feeds avgdl -- a plausible wrong number with no error anywhere. In SniiSectionRefsPB the null bitmap's offset/length is taken for the norms region and bsbf is lost entirely. This PR renumbers both messages back to the shipped layout and appends the two upstream additions after it: sum_total_term_freq becomes 5 and norms becomes 5 in their respective messages. SniiCommonGramsMetadataPB needed no change -- its upstream fields 8-12 were appended, which is the shape every future addition must follow. A new case set asserts the field numbers through protobuf reflection rather than through a byte digest, so the next accidental insert fails with a message naming the field and both tags instead of an opaque checksum mismatch. The twelve SniiWriterGoldenBytes digests were RE-HARVESTED: field tags and the field-number ordering are part of the serialized Core metadata that every SNII segment carries, so all of them moved -- including kGoldenKeywordDocsOnly, whose index has neither norms nor a null bitmap. That one moving is the evidence the change reaches every segment shape rather than one lane. COMPATIBILITY: this changes how existing bytes decode, deliberately. Segments written by an upstream build carrying apache#66052 are not readable afterwards and must be rebuilt; the format is not yet released upstream, so that population is development data only. Segments written by the shipped build become readable, which is the point. ### Release note None ### Check List (For Author) - Test - [ ] Regression test - [x] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need to test or manual test. Explain why: - SniiProtoFieldNumbers.* (4 cases, one per metadata message) - SniiWriterGoldenBytes.* re-harvested and green - Full inverted-index suites: 3210 tests, 0 failures - ./run-be-ut.sh -j 160 --run - Behavior changed: - [ ] No. - [x] Yes. SNII segments written by an upstream build carrying apache#66052 must be rebuilt. - Does this need documentation? - [x] No. - [ ] Yes. ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Member
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 16837 ms |
Contributor
TPC-DS: Total hot run time: 81971 ms |
Contributor
ClickBench: Total hot run time: 16.32 s |
Contributor
FE UT Coverage ReportIncrement line coverage `` 🎉 |
Contributor
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Contributor
FE Regression Coverage ReportIncrement line coverage |
Member
Author
|
run buildall |
Contributor
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
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
2 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.
What problem does this PR solve?
Issue Number: None
Related PR: #66052
Problem Summary: SNII shipped before its metadata messages reached upstream, and
the version upstreamed in #66052 had INSERTED fields in the middle of two of
them rather than appending. protobuf identifies a field by its tag, so the two
layouts now disagree about what a tag means, and every SNII segment already
written decodes incorrectly under the upstream numbering:
SniiStatsPB shipped upstream (#66052)
tag 4 null_count sum_total_term_freq
tag 5 -- null_count
SniiSectionRefsPB shipped upstream (#66052)
tag 3 null_bitmap norms
tag 4 bsbf null_bitmap
tag 5 -- bsbf
Neither misread fails. SniiStatsPB tags 4 and 5 are both uint64, so a null count
is returned as the collection token sum and feeds avgdl -- a plausible wrong
number with no error anywhere. In SniiSectionRefsPB the null bitmap's
offset/length is taken for the norms region and bsbf is lost entirely.
This PR renumbers both messages back to the shipped layout and appends the two
upstream additions after it: sum_total_term_freq becomes 5 and norms becomes 5
in their respective messages. SniiCommonGramsMetadataPB needed no change -- its
upstream fields 8-12 were appended, which is the shape every future addition
must follow.
A new case set asserts the field numbers through protobuf reflection rather than
through a byte digest, so the next accidental insert fails with a message naming
the field and both tags instead of an opaque checksum mismatch.
The twelve SniiWriterGoldenBytes digests were RE-HARVESTED: field tags and the
field-number ordering are part of the serialized Core metadata that every SNII
segment carries, so all of them moved -- including kGoldenKeywordDocsOnly, whose
index has neither norms nor a null bitmap. That one moving is the evidence the
change reaches every segment shape rather than one lane.
COMPATIBILITY: this changes how existing bytes decode, deliberately. Segments
written by an upstream build carrying #66052 are not readable afterwards and
must be rebuilt; the format is not yet released upstream, so that population is
development data only. Segments written by the shipped build become readable,
which is the point.
Release note
None
Check List (For Author)
Test
Behavior changed:
rebuilt.
Does this need documentation?
Check List (For Reviewer who merge this PR)