Skip to content

Add 5 part multi topic segment name#18991

Draft
rseetham wants to merge 12 commits into
apache:masterfrom
rseetham:multi-topic-topicid-name
Draft

Add 5 part multi topic segment name#18991
rseetham wants to merge 12 commits into
apache:masterfrom
rseetham:multi-topic-topicid-name

Conversation

@rseetham

Copy link
Copy Markdown
Contributor

No description provided.

rseetham added 6 commits July 13, 2026 16:14
…e fallback

The fallback branch (used when fetching partition ids directly from the
stream fails) called Map<Integer, Set<Integer>>.add(...), which does not
compile. Restore the fallback to decode each PartitionGroupMetadata's
padded pinot partition id into (topicId, streamPartitionId) using the
existing IngestionConfigUtils helpers, matching the convention already
used in createNewSegmentMetadata/getNextLLCSegmentName, with a pass-through
shortcut for single-stream tables.
…etadata

Fields not yet wired through constructors/getters.
@rseetham
rseetham marked this pull request as draft July 14, 2026 14:02
rseetham added 6 commits July 14, 2026 09:03
…tionStatus

Additive, non-breaking: new constructor overloads accept an explicit
topicId identifying which stream config (topic) a partition group
belongs to, defaulting to 0 when omitted. Wires topicId through
PartitionGroupMetadataFetcher.fetchMultipleStreams using the per-stream
index. No existing callers are changed yet.
…ltimeSegmentManager

buildPartitionGroupConsumptionStatusFromZKMetadata and
getPartitionGroupConsumptionStatusList relied on IngestionConfigUtils
padded-id arithmetic to decode topicId/streamPartitionId, which is wrong
for multi-topic-format segment names where these values are embedded
directly and unpadded. Use LLCSegmentName.getTopicId(true)/
getStreamPartitionGroupId(true) instead, mirroring the pattern already
used elsewhere.
…mentDataManager

The multi-stream constructor branch used IngestionConfigUtils padded-id
arithmetic to decode topicId/streamPartitionId, which is wrong for
multi-topic-format segment names. Use LLCSegmentName.getTopicId(true)/
getStreamPartitionGroupId(true) instead, consistent with
PinotLLCRealtimeSegmentManager. Also fix the Preconditions.checkState
message to reference topicId instead of the old "index" terminology.
fetchMultipleStreams() now sets PartitionGroupMetadata's topicId and
partitionGroupId directly from the loop index and raw stream partition
id, instead of encoding them into a padded composite id via
IngestionConfigUtils. This avoids relying on the padded-id scheme,
which the LLCSegmentName multi-topic format has already moved away
from.
Several call sites in PinotLLCRealtimeSegmentManager decoded topic and
stream partition ids out of a padded composite pinotPartitionId via
IngestionConfigUtils, even though a richer LLCSegmentName or
PartitionGroupMetadata object was already available with direct,
unpadded accessors. Switch those sites to use
LLCSegmentName#getTopicId/getStreamPartitionGroupId and
PartitionGroupMetadata#getTopicId/getPartitionGroupId instead.

Leaves untouched the two call sites that legitimately need
IngestionConfigUtils: decoding a genuinely old-format (padded)
LLCSegmentName in getNextLLCSegmentName, and
getPartitionMetadataFromTableConfig, which only has a raw partition id
and TableConfig, not a richer object.
Watermark previously had no topicId field, forcing getStreamMetadataList
to decode the stream config index from a padded composite partitionGroupId
that is no longer guaranteed to be padded. Add an explicit topicId field
and thread it through getConsumerWatermarks/getStreamMetadataList, using
the decoded stream partition id (not the raw, possibly still-padded one)
when constructing watermarks from PartitionGroupConsumptionStatus.
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (a2a27a1) to head (96ba370).
⚠️ Report is 14 commits behind head on master.

Additional details and impacted files
@@              Coverage Diff               @@
##             master    #18991       +/-   ##
==============================================
+ Coverage     65.05%   100.00%   +34.94%     
+ Complexity     1403         6     -1397     
==============================================
  Files          3399         3     -3396     
  Lines        212808         6   -212802     
  Branches      33568         0    -33568     
==============================================
- Hits         138443         6   -138437     
+ Misses        63223         0    -63223     
+ Partials      11142         0    -11142     
Flag Coverage Δ
custom-integration1 ?
integration 100.00% <ø> (ø)
integration1 100.00% <ø> (ø)
integration2 ?
java-21 100.00% <ø> (+34.94%) ⬆️
temurin 100.00% <ø> (+34.94%) ⬆️
unittests ?
unittests1 ?
unittests2 ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants