airborne12 opened a new pull request, #67135:
URL: https://github.com/apache/doris/pull/67135
### 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
- [ ] 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 #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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
