You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pinot.apache.org by "raghavyadav01 (via GitHub)" <gi...@apache.org> on 2026/10/16 05:08:58 UTC
[PR] Defer a new segment only while its replicas are still coming up [pinot]
raghavyadav01 opened a new pull request, #19901:
URL: https://github.com/apache/pinot/pull/19901
A partition-hinted multi-stage query can silently drop rows of recently added segments.
`SegmentPartitionMetadataManager` leaves a newly created segment out of its partition's info until the segment is online on every server that already holds the partition. That is meant for a segment whose replicas are still loading, so a half-online segment does not shrink the partition's fully replicated servers.
The same check also excludes a segment that is already online on every server it is assigned to, just on different servers than the rest of its partition. That happens on any partitioned table without partition-aware instance assignment, where segments of one partition are spread across servers. Such a segment never covers the partition's servers, so it stays out for the whole new-segment window. A leaf assigned by partition (`tableOptions(partition_key=..., partition_size=...)`) then dispatches the partition without it, and its rows are skipped with no error. Once the segment stops being new, it is counted and the same query fails with `Failed to find enabled fully replicated server`. So the result depends on how long ago the segment was added.
Measured on a 3-server cluster, two tables bucketed 4 ways on the join key, 2 segments per partition spread by the default assignment, queried shortly after the segments were added:
| | colocated join (`is_colocated_by_join_keys` + `tableOptions`) | shuffled join |
|---|---|---|
| before | **23 rows**, no error | 60 rows |
| after | `Failed to find enabled fully replicated server for table: ..., partition: 0` | 60 rows |
With partition-aware instance assignment in place, the hinted join returns 60 rows both before and after this change.
**Fix:** record how many replicas the ideal state assigns each segment (in ONLINE or CONSUMING state), and defer a new segment only while fewer of them are online. A new segment that is online on all of its assigned replicas is counted like any other segment, so a partition that no single server holds whole is reported immediately rather than hidden for the length of the new-segment window. A segment the ideal state does not list keeps the current behaviour.
**Behaviour change:** on a partitioned table without partition-aware placement, a partition-hinted query now fails with the existing "no fully replicated server" error as soon as a new segment comes online elsewhere, instead of returning partial results for up to the new-segment expiration and failing afterwards. A segment that is still coming up is deferred exactly as before.
**Testing:** `testFullyOnlineNewSegmentOnOtherServersIsNotDeferred` covers both sides (a segment still coming up stays deferred; a fully online one on other servers is counted and the partition reports no fully replicated server) and fails without the change. `pinot-broker` routing tests (269) and `WorkerManagerTest` / `ColocationGroupAnalyzerTest` (97) pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Defer a new segment only while its replicas are still coming up [pinot]
Posted by "raghavyadav01 (via GitHub)" <gi...@apache.org>.
raghavyadav01 merged PR #19901:
URL: https://github.com/apache/pinot/pull/19901
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Defer a new segment only while its replicas are still coming up [pinot]
Posted by "xiangfu0 (via GitHub)" <gi...@apache.org>.
xiangfu0 commented on code in PR #19901:
URL: https://github.com/apache/pinot/pull/19901#discussion_r4297561433
##########
pinot-broker/src/main/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManager.java:
##########
@@ -458,11 +484,26 @@ private static class SegmentInfo {
int _partitionId;
long _creationTimeMs;
List<String> _onlineServers;
+ /// Servers the ideal state assigns the segment to in ONLINE or CONSUMING state; empty when the ideal state does
+ /// not list it, or lists it only in other states (e.g. OFFLINE while it is being dropped).
+ List<String> _assignedServers;
- SegmentInfo(int partitionId, long creationTimeMs, List<String> onlineServers) {
+ SegmentInfo(int partitionId, long creationTimeMs, List<String> onlineServers, List<String> assignedServers) {
_partitionId = partitionId;
_creationTimeMs = creationTimeMs;
_onlineServers = onlineServers;
+ _assignedServers = assignedServers;
+ }
+
+ /// Whether every server the ideal state assigns the segment to has it online, i.e. it is not still coming up.
+ ///
+ /// Compares the server sets rather than their sizes: the ideal state and external view are updated independently,
+ /// so during a reassignment the external view can still list a server the ideal state has dropped, matching the
+ /// assigned count while an assigned replica is still down. An empty assignment returns false, which keeps
+ /// deferring a segment whose readiness cannot be judged -- the behaviour before assignments were tracked.
+ boolean hasAllAssignedReplicasOnline() {
+ //noinspection SlowListContainsAll
+ return !_assignedServers.isEmpty() && _onlineServers.containsAll(_assignedServers);
Review Comment:
This fully addresses my earlier note — switching to `containsAll` on the actual assigned server set removes the cross-source count mismatch, so a segment mid-reassignment with matching counts but a still-down replica now stays deferred. The Javadoc explaining why sets beat sizes is a great touch.
##########
pinot-broker/src/test/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManagerTest.java:
##########
@@ -295,6 +295,81 @@ public void testPartitionMetadataManagerProcessingThroughSegmentChangesSinglePar
assertEquals(tablePartitionReplicatedServersInfo.getSegmentsWithInvalidPartition().get(0), segmentInvalid);
}
+ /// A new segment is deferred only while its replicas are still coming up. One that is already online on every server
+ /// the ideal state assigns, but on other servers than the rest of its partition, will never cover them: deferring it
+ /// made a partition-hinted query silently skip its rows until it stopped being new. It must instead count like an
+ /// old segment, so the partition reports that no server holds all of it.
+ @Test
+ public void testFullyOnlineNewSegmentOnOtherServersIsNotDeferred() {
+ ExternalView externalView = new ExternalView(OFFLINE_TABLE_NAME);
+ Map<String, Map<String, String>> segmentAssignment = externalView.getRecord().getMapFields();
+ IdealState idealState = new IdealState(OFFLINE_TABLE_NAME);
+ Map<String, Map<String, String>> idealAssignment = idealState.getRecord().getMapFields();
+ Set<String> onlineSegments = new HashSet<>();
+
+ SegmentPartitionMetadataManager partitionMetadataManager =
+ new SegmentPartitionMetadataManager(OFFLINE_TABLE_NAME, PARTITION_COLUMN, PARTITION_COLUMN_FUNC, NUM_PARTITIONS,
+ TimeUnit.MINUTES.toMillis(5));
+ SegmentZkMetadataFetcher segmentZkMetadataFetcher =
+ new SegmentZkMetadataFetcher(OFFLINE_TABLE_NAME, _propertyStore);
+ segmentZkMetadataFetcher.register(partitionMetadataManager);
+ segmentZkMetadataFetcher.init(idealState, externalView, onlineSegments);
+
+ // An old segment of partition 0 on server0.
+ String oldSegment = "oldSegment";
+ onlineSegments.add(oldSegment);
+ idealAssignment.put(oldSegment, Map.of(SERVER_0, ONLINE));
+ segmentAssignment.put(oldSegment, Map.of(SERVER_0, ONLINE));
+ setSegmentZKMetadata(oldSegment, PARTITION_COLUMN_FUNC, NUM_PARTITIONS, 0, 0L);
+
+ // A new segment of partition 0 still coming up: assigned to server0 and server1, online on server1 only.
+ String comingUp = "comingUpSegment";
+ onlineSegments.add(comingUp);
+ idealAssignment.put(comingUp, Map.of(SERVER_0, ONLINE, SERVER_1, ONLINE));
+ segmentAssignment.put(comingUp, Map.of(SERVER_1, ONLINE));
+ setSegmentZKMetadata(comingUp, PARTITION_COLUMN_FUNC, NUM_PARTITIONS, 0, System.currentTimeMillis());
+ segmentZkMetadataFetcher.onAssignmentChange(idealState, externalView, onlineSegments);
+
+ TablePartitionReplicatedServersInfo.PartitionInfo[] partitionInfoMap =
+ partitionMetadataManager.getTablePartitionReplicatedServersInfo().getPartitionInfoMap();
+ assertEquals(partitionInfoMap[0]._segments, List.of(oldSegment), "a segment still coming up stays deferred");
+ assertEquals(partitionInfoMap[0]._fullyReplicatedServers, Set.of(SERVER_0));
+
+ // A new segment of partition 0 fully online, but only on server1 -- the default spread of a table without
+ // partition-aware placement.
+ String placedElsewhere = "placedElsewhereSegment";
+ onlineSegments.add(placedElsewhere);
+ idealAssignment.put(placedElsewhere, Map.of(SERVER_1, ONLINE));
+ segmentAssignment.put(placedElsewhere, Map.of(SERVER_1, ONLINE));
+ setSegmentZKMetadata(placedElsewhere, PARTITION_COLUMN_FUNC, NUM_PARTITIONS, 0, System.currentTimeMillis());
+ segmentZkMetadataFetcher.onAssignmentChange(idealState, externalView, onlineSegments);
+
+ partitionInfoMap = partitionMetadataManager.getTablePartitionReplicatedServersInfo().getPartitionInfoMap();
+ assertEqualsNoOrder(partitionInfoMap[0]._segments.toArray(), new String[]{oldSegment, placedElsewhere});
+ assertTrue(partitionInfoMap[0]._fullyReplicatedServers.isEmpty(),
+ "no server holds every segment of the partition, and the info must say so rather than hide a segment");
+
+ // A new segment of partition 1 mid-reassignment: the ideal state moved it to server0 and server1, while the
+ // external view still lists the server it is leaving next to server1. Two online servers match the two assigned,
+ // yet assigned server0 is still down, so the segment is still coming up and must stay deferred.
+ String oldSegment1 = "oldSegment1";
+ onlineSegments.add(oldSegment1);
+ idealAssignment.put(oldSegment1, Map.of(SERVER_0, ONLINE, SERVER_1, ONLINE));
+ segmentAssignment.put(oldSegment1, Map.of(SERVER_0, ONLINE, SERVER_1, ONLINE));
+ setSegmentZKMetadata(oldSegment1, PARTITION_COLUMN_FUNC, NUM_PARTITIONS, 1, 0L);
+ String midReassignment = "midReassignmentSegment";
+ onlineSegments.add(midReassignment);
+ idealAssignment.put(midReassignment, Map.of(SERVER_0, ONLINE, SERVER_1, ONLINE));
+ segmentAssignment.put(midReassignment, Map.of(SERVER_1, ONLINE, "leavingServer", ONLINE));
+ setSegmentZKMetadata(midReassignment, PARTITION_COLUMN_FUNC, NUM_PARTITIONS, 1, System.currentTimeMillis());
+ segmentZkMetadataFetcher.onAssignmentChange(idealState, externalView, onlineSegments);
+
+ partitionInfoMap = partitionMetadataManager.getTablePartitionReplicatedServersInfo().getPartitionInfoMap();
+ assertEquals(partitionInfoMap[1]._segments, List.of(oldSegment1),
Review Comment:
The mid-reassignment case is exactly the window I was worried about, and it would fail under the old count-based check. Good to have it pinned down as a regression test.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Defer a new segment only while its replicas are still coming up [pinot]
Posted by "xiangfu0 (via GitHub)" <gi...@apache.org>.
xiangfu0 commented on code in PR #19901:
URL: https://github.com/apache/pinot/pull/19901#discussion_r4291429713
##########
pinot-broker/src/main/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManager.java:
##########
@@ -383,6 +408,17 @@ private void computeTablePartitionReplicatedServersInfo() {
//noinspection SlowListContainsAll
if (onlineServers.containsAll(partitionInfo._fullyReplicatedServers)) {
partitionInfo._segments.add(segment);
+ } else if (segmentInfo.hasAllAssignedReplicasOnline()) {
Review Comment:
Nice, this is the heart of the fix and reads clearly. One thing to confirm: when this branch runs, `retainAll` can empty `fullyReplicatedServers`, and the downstream `WorkerManager` then throws "Failed to find enabled fully replicated server" for a partition-hinted leaf. That is the intended trade (a loud error instead of silently dropped rows), and the PR body documents it well — just flagging that operators of partitioned tables without partition-aware placement will start seeing that error immediately rather than after the new-segment window.
##########
pinot-broker/src/test/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManagerTest.java:
##########
@@ -295,6 +295,61 @@ public void testPartitionMetadataManagerProcessingThroughSegmentChangesSinglePar
assertEquals(tablePartitionReplicatedServersInfo.getSegmentsWithInvalidPartition().get(0), segmentInvalid);
}
+ /// A new segment is deferred only while its replicas are still coming up. One that is already online on every server
+ /// the ideal state assigns, but on other servers than the rest of its partition, will never cover them: deferring it
+ /// made a partition-hinted query silently skip its rows until it stopped being new. It must instead count like an
+ /// old segment, so the partition reports that no server holds all of it.
+ @Test
+ public void testFullyOnlineNewSegmentOnOtherServersIsNotDeferred() {
+ ExternalView externalView = new ExternalView(OFFLINE_TABLE_NAME);
+ Map<String, Map<String, String>> segmentAssignment = externalView.getRecord().getMapFields();
+ IdealState idealState = new IdealState(OFFLINE_TABLE_NAME);
+ Map<String, Map<String, String>> idealAssignment = idealState.getRecord().getMapFields();
+ Set<String> onlineSegments = new HashSet<>();
+
+ SegmentPartitionMetadataManager partitionMetadataManager =
+ new SegmentPartitionMetadataManager(OFFLINE_TABLE_NAME, PARTITION_COLUMN, PARTITION_COLUMN_FUNC, NUM_PARTITIONS,
+ TimeUnit.MINUTES.toMillis(5));
+ SegmentZkMetadataFetcher segmentZkMetadataFetcher =
+ new SegmentZkMetadataFetcher(OFFLINE_TABLE_NAME, _propertyStore);
+ segmentZkMetadataFetcher.register(partitionMetadataManager);
+ segmentZkMetadataFetcher.init(idealState, externalView, onlineSegments);
+
+ // An old segment of partition 0 on server0.
+ String oldSegment = "oldSegment";
+ onlineSegments.add(oldSegment);
+ idealAssignment.put(oldSegment, Map.of(SERVER_0, ONLINE));
+ segmentAssignment.put(oldSegment, Map.of(SERVER_0, ONLINE));
+ setSegmentZKMetadata(oldSegment, PARTITION_COLUMN_FUNC, NUM_PARTITIONS, 0, 0L);
+
+ // A new segment of partition 0 still coming up: assigned to server0 and server1, online on server1 only.
Review Comment:
This test nicely covers the two main cases. Would you consider adding one more for the IS/EV divergence window — a segment whose IS assigns {server0, server1} but whose EV shows server1 plus a stale server0 entry while the real new replica is still down? That is the case where the count comparison in `hasAllAssignedReplicasOnline()` can admit a segment that is still coming up, so a test there would pin down the intended behaviour.
##########
pinot-broker/src/main/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManager.java:
##########
@@ -230,12 +247,20 @@ public synchronized void onAssignmentChange(IdealState idealState, ExternalView
LOGGER.error("Failed to find segment info for segment: {} in table: {} while handling assignment change",
segment, _tableNameWithType);
segmentInfo = new SegmentInfo(INVALID_PARTITION_ID, INVALID_CREATION_TIME_MS,
- getOnlineServers(instanceStateMap, onlineServersCache));
+ getOnlineServers(instanceStateMap, onlineServersCache),
+ getNumAssignedReplicas(idealState.getInstanceStateMap(segment)));
_segmentInfoMap.put(segment, segmentInfo);
partitionsChanged = true;
- } else if (!hasSameOnlineServers(segmentInfo._onlineServers, instanceStateMap)) {
- segmentInfo._onlineServers = getOnlineServers(instanceStateMap, onlineServersCache);
- onlineServersChanged = true;
+ } else {
+ if (!hasSameOnlineServers(segmentInfo._onlineServers, instanceStateMap)) {
+ segmentInfo._onlineServers = getOnlineServers(instanceStateMap, onlineServersCache);
+ onlineServersChanged = true;
+ }
+ int numAssignedReplicas = getNumAssignedReplicas(idealState.getInstanceStateMap(segment));
+ if (segmentInfo._numAssignedReplicas != numAssignedReplicas) {
+ segmentInfo._numAssignedReplicas = numAssignedReplicas;
+ onlineServersChanged = true;
Review Comment:
Setting `onlineServersChanged = true` here correctly forces a recompute when only the assigned-replica count changed, so the behaviour is right. The flag name is now a little misleading though, since it no longer strictly means the online servers changed — maybe rename to something like `recomputeNeeded` or add a short comment so it doesn't trip someone up later.
##########
pinot-broker/src/main/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManager.java:
##########
@@ -458,11 +494,20 @@ private static class SegmentInfo {
int _partitionId;
long _creationTimeMs;
List<String> _onlineServers;
+ /// Replicas the ideal state assigns in ONLINE or CONSUMING state; 0 when the ideal state does not list the segment.
+ int _numAssignedReplicas;
- SegmentInfo(int partitionId, long creationTimeMs, List<String> onlineServers) {
+ SegmentInfo(int partitionId, long creationTimeMs, List<String> onlineServers, int numAssignedReplicas) {
_partitionId = partitionId;
_creationTimeMs = creationTimeMs;
_onlineServers = onlineServers;
+ _numAssignedReplicas = numAssignedReplicas;
+ }
+
+ /// Whether the segment is online on as many servers as the ideal state assigns it to, i.e. it is not still coming
+ /// up. False when the ideal state does not list it, which keeps treating such a segment as not ready.
+ boolean hasAllAssignedReplicasOnline() {
+ return _numAssignedReplicas > 0 && _onlineServers.size() >= _numAssignedReplicas;
Review Comment:
This readiness check compares an ExternalView count (`_onlineServers.size()`) against an IdealState count (`_numAssignedReplicas`), and the two come from eventually-consistent sources with overlapping but not identical server sets. During a reassignment or drain, the EV can briefly still list an old ONLINE server that the IS no longer assigns, so the size can reach the assigned count while a genuinely assigned replica is still coming up — which is exactly the case this PR wants to keep deferring.
Could we test set-containment instead, i.e. that every IS-assigned server is present in `_onlineServers`? That would need keeping the assigned server set rather than just the count, but it removes the cross-source mismatch. The `>=` itself looks like the right choice given a count compare (it tolerates an extra EV server); the concern is the count compare, not the operator.
##########
pinot-broker/src/main/java/org/apache/pinot/broker/routing/segmentpartition/SegmentPartitionMetadataManager.java:
##########
@@ -173,6 +174,21 @@ private static boolean isOnline(String instanceState) {
return instanceState.equals(SegmentStateModel.ONLINE) || instanceState.equals(SegmentStateModel.CONSUMING);
}
+ /// Returns the number of servers the ideal state assigns the segment to in ONLINE or CONSUMING state, or 0 when the
+ /// ideal state does not list it.
+ private static int getNumAssignedReplicas(@Nullable Map<String, String> idealInstanceStateMap) {
+ if (idealInstanceStateMap == null) {
+ return 0;
+ }
+ int numAssignedReplicas = 0;
+ for (String instanceState : idealInstanceStateMap.values()) {
+ if (isOnline(instanceState)) {
+ numAssignedReplicas++;
+ }
+ }
+ return numAssignedReplicas;
Review Comment:
Small thing worth a comment: the `isOnline` filter here means a segment whose IS replicas are all OFFLINE (e.g. being dropped) gets `_numAssignedReplicas == 0`, so `hasAllAssignedReplicasOnline()` returns false and it stays deferred. That looks like the safe fallback you intend, but it's subtle enough that a one-line note on why 0 means "keep deferring" would help the next reader.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Defer a new segment only while its replicas are still coming up [pinot]
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #19901:
URL: https://github.com/apache/pinot/pull/19901#issuecomment-6209595001
## [Codecov](https://app.codecov.io/gh/apache/pinot/pull/19901?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 58.89%. Comparing base ([`8705c08`](https://app.codecov.io/gh/apache/pinot/commit/8705c08339413a43bf2e13b925e06a0c5833c59c?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`11f2817`](https://app.codecov.io/gh/apache/pinot/commit/11f28179e3b45f5c9eab9fae35c8bbeae9ee7884?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
:warning: Report is 1 commits behind head on master.
> :exclamation: There is a different number of reports uploaded between BASE (8705c08) and HEAD (11f2817). Click for more details.
>
> <details><summary>HEAD has 14 uploads less than BASE</summary>
>
>| Flag | BASE (8705c08) | HEAD (11f2817) |
>|------|------|------|
>|lane-a|2|1|
>|integration|4|2|
>|java-25|6|3|
>|temurin|6|3|
>|lane-b|2|1|
>|unittests2|1|0|
>|unittests|2|1|
>|integration2|2|0|
></details>
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## master #19901 +/- ##
=============================================
- Coverage 69.39% 58.89% -10.51%
+ Complexity 1491 7 -1484
=============================================
Files 3544 2730 -814
Lines 233616 171257 -62359
Branches 37371 28201 -9170
=============================================
- Hits 162116 100855 -61261
- Misses 58960 61906 +2946
+ Partials 12540 8496 -4044
```
| [Flag](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | |
|---|---|---|
| [integration](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `100.00% <ø> (ø)` | |
| [integration1](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `100.00% <ø> (ø)` | |
| [integration2](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [java-25](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `58.89% <ø> (-10.51%)` | :arrow_down: |
| [lane-a](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `100.00% <ø> (ø)` | |
| [lane-b](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `0.00% <ø> (ø)` | |
| [temurin](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `58.89% <ø> (-10.51%)` | :arrow_down: |
| [unittests](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `58.88% <ø> (-10.51%)` | :arrow_down: |
| [unittests1](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `58.88% <ø> (+<0.01%)` | :arrow_up: |
| [unittests2](https://app.codecov.io/gh/apache/pinot/pull/19901/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#carryforward-flags-in-the-pull-request-comment) to find out more.
</details>
[:umbrella: View full report in Codecov by Harness](https://app.codecov.io/gh/apache/pinot/pull/19901?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
<details><summary> :rocket: New features to boost your workflow: </summary>
- :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
</details>
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org