You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pinot.apache.org by "xiangfu0 (via GitHub)" <gi...@apache.org> on 2026/04/16 19:18:46 UTC
[PR] [Flaky Test] Fix ExactlyOnceKafkaRealtimeClusterIntegrationTest countRecords early termination [pinot]
xiangfu0 opened a new pull request, #18238:
URL: https://github.com/apache/pinot/pull/18238
## Summary
- `ExactlyOnceKafkaRealtimeClusterIntegrationTest.countRecords` broke on the first empty poll. On a freshly assigned consumer the first poll frequently returns empty while metadata/fetch sessions are being established — especially in `read_committed` mode where the broker has to resolve the LSO — so the test mis-read that as "no records" and `waitForCommittedRecordsVisible` threw the misleading "transaction markers were not propagated" error even though `commitTransaction()` had already blocked until the markers were written.
- Corroborating evidence: the failure line shows `read_committed=0, read_uncommitted=154634`, and 154 634 is well below 2×115 545 expected for two full passes of the dataset, i.e. the helper was also under-counting in `read_uncommitted` mode.
- Rewrite the loop to take an `endOffsets` snapshot (the LSO under `read_committed`) and drain until every partition's `position` catches up, priming the consumer with a short `poll(200ms)` first so `endOffsets()` and `position()` do not block on cold metadata. Log exceptions with stack traces and log the `endOffsets==0` short-circuit so a transient metadata timeout is distinguishable from a genuinely empty topic in CI output.
## Test plan
- [x] `./mvnw spotless:apply -pl pinot-integration-tests`
- [x] `./mvnw checkstyle:check -pl pinot-integration-tests`
- [x] `./mvnw -pl pinot-integration-tests -am test-compile`
- [ ] CI: `ExactlyOnceKafkaRealtimeClusterIntegrationTest` passes consistently
--
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] [Flaky Test] Fix ExactlyOnceKafkaRealtimeClusterIntegrationTest countRecords early termination [pinot]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #18238:
URL: https://github.com/apache/pinot/pull/18238#discussion_r3095798219
##########
pinot-integration-tests/src/test/java/org/apache/pinot/integration/tests/ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:
##########
@@ -265,27 +273,53 @@ private int countRecords(String brokerList, String isolationLevel) {
LOGGER.warn("No partitions found for topic {}", getKafkaTopic());
return 0;
}
+ List<TopicPartition> topicPartitions = new ArrayList<>(partitions.size());
for (PartitionInfo pi : partitions) {
- TopicPartition tp = new TopicPartition(pi.topic(), pi.partition());
- consumer.assign(Collections.singletonList(tp));
- consumer.seekToBeginning(Collections.singletonList(tp));
- long deadline = System.currentTimeMillis() + 30_000L;
- int partitionRecords = 0;
- while (System.currentTimeMillis() < deadline) {
- ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(5));
- if (records.isEmpty()) {
- break;
- }
- partitionRecords += records.count();
+ topicPartitions.add(new TopicPartition(pi.topic(), pi.partition()));
+ }
+ consumer.assign(topicPartitions);
+ consumer.seekToBeginning(topicPartitions);
+ // Prime the consumer's metadata/fetch session with a short poll so the subsequent
+ // endOffsets() and position() calls do not block on cold metadata resolution.
+ consumer.poll(Duration.ofMillis(200));
+ Map<TopicPartition, Long> endOffsets = consumer.endOffsets(topicPartitions, Duration.ofSeconds(10));
+ long expectedTotal = 0L;
+ for (Long offset : endOffsets.values()) {
+ expectedTotal += offset;
+ }
+ if (expectedTotal == 0L) {
+ // Two distinct cases, both correctly returning 0:
+ // - read_committed: LSO is at 0 on every partition, i.e. no transaction has been finalized yet.
+ // - read_uncommitted: the topic is genuinely empty.
+ // A transient endOffsets timeout would also land here; log so it is distinguishable in CI output.
Review Comment:
The comment says “A transient endOffsets timeout would also land here”, but `KafkaConsumer.endOffsets(..., Duration)` typically throws `TimeoutException` rather than returning 0s. Either adjust the comment to match the actual behavior, or handle/log the timeout case explicitly so CI output isn’t misleading.
```suggestion
// A timeout from endOffsets(...) is handled by the exception path below, so reaching here means the
// broker returned 0 for every partition.
```
##########
pinot-integration-tests/src/test/java/org/apache/pinot/integration/tests/ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:
##########
@@ -265,27 +273,53 @@ private int countRecords(String brokerList, String isolationLevel) {
LOGGER.warn("No partitions found for topic {}", getKafkaTopic());
return 0;
}
+ List<TopicPartition> topicPartitions = new ArrayList<>(partitions.size());
for (PartitionInfo pi : partitions) {
- TopicPartition tp = new TopicPartition(pi.topic(), pi.partition());
- consumer.assign(Collections.singletonList(tp));
- consumer.seekToBeginning(Collections.singletonList(tp));
- long deadline = System.currentTimeMillis() + 30_000L;
- int partitionRecords = 0;
- while (System.currentTimeMillis() < deadline) {
- ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(5));
- if (records.isEmpty()) {
- break;
- }
- partitionRecords += records.count();
+ topicPartitions.add(new TopicPartition(pi.topic(), pi.partition()));
+ }
+ consumer.assign(topicPartitions);
+ consumer.seekToBeginning(topicPartitions);
+ // Prime the consumer's metadata/fetch session with a short poll so the subsequent
+ // endOffsets() and position() calls do not block on cold metadata resolution.
+ consumer.poll(Duration.ofMillis(200));
Review Comment:
`consumer.poll(Duration.ofMillis(200))` can return records and also advance the consumer position, but the result is ignored. This can under-count (and potentially hit the caught-up condition without ever incrementing `totalRecords`). Consider either adding the priming poll’s `records.count()` into `totalRecords`, or re-seeking to beginning after the priming poll so no records are skipped.
```suggestion
// Count any records returned here because poll() can advance the consumer position.
ConsumerRecords<byte[], byte[]> initialRecords = consumer.poll(Duration.ofMillis(200));
totalRecords += initialRecords.count();
```
##########
pinot-integration-tests/src/test/java/org/apache/pinot/integration/tests/ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:
##########
@@ -265,27 +273,53 @@ private int countRecords(String brokerList, String isolationLevel) {
LOGGER.warn("No partitions found for topic {}", getKafkaTopic());
return 0;
}
+ List<TopicPartition> topicPartitions = new ArrayList<>(partitions.size());
for (PartitionInfo pi : partitions) {
- TopicPartition tp = new TopicPartition(pi.topic(), pi.partition());
- consumer.assign(Collections.singletonList(tp));
- consumer.seekToBeginning(Collections.singletonList(tp));
- long deadline = System.currentTimeMillis() + 30_000L;
- int partitionRecords = 0;
- while (System.currentTimeMillis() < deadline) {
- ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(5));
- if (records.isEmpty()) {
- break;
- }
- partitionRecords += records.count();
+ topicPartitions.add(new TopicPartition(pi.topic(), pi.partition()));
+ }
+ consumer.assign(topicPartitions);
+ consumer.seekToBeginning(topicPartitions);
+ // Prime the consumer's metadata/fetch session with a short poll so the subsequent
+ // endOffsets() and position() calls do not block on cold metadata resolution.
+ consumer.poll(Duration.ofMillis(200));
+ Map<TopicPartition, Long> endOffsets = consumer.endOffsets(topicPartitions, Duration.ofSeconds(10));
+ long expectedTotal = 0L;
+ for (Long offset : endOffsets.values()) {
+ expectedTotal += offset;
+ }
+ if (expectedTotal == 0L) {
Review Comment:
`expectedTotal` is computed as the sum of absolute end offsets and is only used to detect the “all zero” case. Renaming it to something like `endOffsetSum` / `totalEndOffset` (or replacing it with an `allZero` boolean check) would make the intent clearer and avoid implying it is an expected record count.
```suggestion
long totalEndOffset = 0L;
for (Long offset : endOffsets.values()) {
totalEndOffset += offset;
}
if (totalEndOffset == 0L) {
```
--
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] [Flaky Test] Fix ExactlyOnceKafkaRealtimeClusterIntegrationTest countRecords early termination [pinot]
Posted by "xiangfu0 (via GitHub)" <gi...@apache.org>.
xiangfu0 merged PR #18238:
URL: https://github.com/apache/pinot/pull/18238
--
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] [Flaky Test] Fix ExactlyOnceKafkaRealtimeClusterIntegrationTest countRecords early termination [pinot]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #18238:
URL: https://github.com/apache/pinot/pull/18238#discussion_r3095966294
##########
pinot-integration-tests/src/test/java/org/apache/pinot/integration/tests/ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:
##########
@@ -265,27 +273,57 @@ private int countRecords(String brokerList, String isolationLevel) {
LOGGER.warn("No partitions found for topic {}", getKafkaTopic());
return 0;
}
+ List<TopicPartition> topicPartitions = new ArrayList<>(partitions.size());
for (PartitionInfo pi : partitions) {
- TopicPartition tp = new TopicPartition(pi.topic(), pi.partition());
- consumer.assign(Collections.singletonList(tp));
- consumer.seekToBeginning(Collections.singletonList(tp));
- long deadline = System.currentTimeMillis() + 30_000L;
- int partitionRecords = 0;
- while (System.currentTimeMillis() < deadline) {
- ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(5));
- if (records.isEmpty()) {
- break;
- }
- partitionRecords += records.count();
+ topicPartitions.add(new TopicPartition(pi.topic(), pi.partition()));
+ }
+ consumer.assign(topicPartitions);
+ consumer.seekToBeginning(topicPartitions);
+ // Prime the consumer's metadata/fetch session with a short poll so the subsequent
+ // endOffsets() and position() calls do not block on cold metadata resolution. Any records
+ // returned here advance the consumer position and must be counted, otherwise we could return
+ // a caught-up position with totalRecords==0.
+ ConsumerRecords<byte[], byte[]> primingRecords = consumer.poll(Duration.ofMillis(200));
+ totalRecords += primingRecords.count();
+ Map<TopicPartition, Long> endOffsets = consumer.endOffsets(topicPartitions, Duration.ofSeconds(10));
+ long totalEndOffset = 0L;
+ for (Long offset : endOffsets.values()) {
+ totalEndOffset += offset;
+ }
+ if (totalEndOffset == 0L) {
+ // Two cases, both correctly returning 0:
+ // - read_committed: LSO is at 0 on every partition, i.e. no transaction has been finalized yet.
+ // - read_uncommitted: the topic is genuinely empty.
+ // A timeout from endOffsets() throws TimeoutException and goes to the catch block below,
+ // so reaching here means the broker returned 0 for every partition.
+ LOGGER.info("countRecords({}): endOffsets returned 0 for all partitions ({})", isolationLevel, endOffsets);
+ return totalRecords;
+ }
+ long deadline = System.currentTimeMillis() + 60_000L;
+ while (System.currentTimeMillis() < deadline) {
Review Comment:
The method hard-codes several timing constants (e.g., `60_000L` and the poll/endOffsets durations). There is already a `KAFKA_TOPIC_METADATA_READY_TIMEOUT_MS` constant in this class; consider introducing a dedicated `COUNT_RECORDS_TIMEOUT_MS` (or reusing an existing constant where appropriate) to avoid magic numbers and make future tuning easier.
##########
pinot-integration-tests/src/test/java/org/apache/pinot/integration/tests/ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:
##########
@@ -265,27 +273,57 @@ private int countRecords(String brokerList, String isolationLevel) {
LOGGER.warn("No partitions found for topic {}", getKafkaTopic());
return 0;
}
+ List<TopicPartition> topicPartitions = new ArrayList<>(partitions.size());
for (PartitionInfo pi : partitions) {
- TopicPartition tp = new TopicPartition(pi.topic(), pi.partition());
- consumer.assign(Collections.singletonList(tp));
- consumer.seekToBeginning(Collections.singletonList(tp));
- long deadline = System.currentTimeMillis() + 30_000L;
- int partitionRecords = 0;
- while (System.currentTimeMillis() < deadline) {
- ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(5));
- if (records.isEmpty()) {
- break;
- }
- partitionRecords += records.count();
+ topicPartitions.add(new TopicPartition(pi.topic(), pi.partition()));
+ }
+ consumer.assign(topicPartitions);
+ consumer.seekToBeginning(topicPartitions);
+ // Prime the consumer's metadata/fetch session with a short poll so the subsequent
+ // endOffsets() and position() calls do not block on cold metadata resolution. Any records
+ // returned here advance the consumer position and must be counted, otherwise we could return
+ // a caught-up position with totalRecords==0.
+ ConsumerRecords<byte[], byte[]> primingRecords = consumer.poll(Duration.ofMillis(200));
+ totalRecords += primingRecords.count();
+ Map<TopicPartition, Long> endOffsets = consumer.endOffsets(topicPartitions, Duration.ofSeconds(10));
+ long totalEndOffset = 0L;
+ for (Long offset : endOffsets.values()) {
+ totalEndOffset += offset;
+ }
+ if (totalEndOffset == 0L) {
+ // Two cases, both correctly returning 0:
+ // - read_committed: LSO is at 0 on every partition, i.e. no transaction has been finalized yet.
+ // - read_uncommitted: the topic is genuinely empty.
+ // A timeout from endOffsets() throws TimeoutException and goes to the catch block below,
+ // so reaching here means the broker returned 0 for every partition.
+ LOGGER.info("countRecords({}): endOffsets returned 0 for all partitions ({})", isolationLevel, endOffsets);
+ return totalRecords;
+ }
+ long deadline = System.currentTimeMillis() + 60_000L;
+ while (System.currentTimeMillis() < deadline) {
+ if (allPartitionsCaughtUp(consumer, topicPartitions, endOffsets)) {
+ break;
}
Review Comment:
If the while-loop exits due to hitting the deadline (rather than `allPartitionsCaughtUp`), the method silently returns a partial/undercounted result, which can still lead to misleading failures downstream. Consider detecting the timeout case and logging the current `position()` vs `endOffsets` (or failing the test) so CI output clearly distinguishes "didn't catch up in time" from "0 records".
##########
pinot-integration-tests/src/test/java/org/apache/pinot/integration/tests/ExactlyOnceKafkaRealtimeClusterIntegrationTest.java:
##########
@@ -265,27 +273,57 @@ private int countRecords(String brokerList, String isolationLevel) {
LOGGER.warn("No partitions found for topic {}", getKafkaTopic());
return 0;
}
+ List<TopicPartition> topicPartitions = new ArrayList<>(partitions.size());
for (PartitionInfo pi : partitions) {
- TopicPartition tp = new TopicPartition(pi.topic(), pi.partition());
- consumer.assign(Collections.singletonList(tp));
- consumer.seekToBeginning(Collections.singletonList(tp));
- long deadline = System.currentTimeMillis() + 30_000L;
- int partitionRecords = 0;
- while (System.currentTimeMillis() < deadline) {
- ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(5));
- if (records.isEmpty()) {
- break;
- }
- partitionRecords += records.count();
+ topicPartitions.add(new TopicPartition(pi.topic(), pi.partition()));
+ }
+ consumer.assign(topicPartitions);
+ consumer.seekToBeginning(topicPartitions);
+ // Prime the consumer's metadata/fetch session with a short poll so the subsequent
+ // endOffsets() and position() calls do not block on cold metadata resolution. Any records
+ // returned here advance the consumer position and must be counted, otherwise we could return
+ // a caught-up position with totalRecords==0.
+ ConsumerRecords<byte[], byte[]> primingRecords = consumer.poll(Duration.ofMillis(200));
+ totalRecords += primingRecords.count();
+ Map<TopicPartition, Long> endOffsets = consumer.endOffsets(topicPartitions, Duration.ofSeconds(10));
+ long totalEndOffset = 0L;
+ for (Long offset : endOffsets.values()) {
+ totalEndOffset += offset;
+ }
+ if (totalEndOffset == 0L) {
+ // Two cases, both correctly returning 0:
+ // - read_committed: LSO is at 0 on every partition, i.e. no transaction has been finalized yet.
+ // - read_uncommitted: the topic is genuinely empty.
+ // A timeout from endOffsets() throws TimeoutException and goes to the catch block below,
+ // so reaching here means the broker returned 0 for every partition.
+ LOGGER.info("countRecords({}): endOffsets returned 0 for all partitions ({})", isolationLevel, endOffsets);
+ return totalRecords;
+ }
+ long deadline = System.currentTimeMillis() + 60_000L;
+ while (System.currentTimeMillis() < deadline) {
+ if (allPartitionsCaughtUp(consumer, topicPartitions, endOffsets)) {
+ break;
}
- totalRecords += partitionRecords;
+ ConsumerRecords<byte[], byte[]> records = consumer.poll(Duration.ofSeconds(2));
+ totalRecords += records.count();
}
} catch (Exception e) {
- LOGGER.error("Error counting records with {}: {}", isolationLevel, e.getMessage());
+ LOGGER.error("Error counting records with {}", isolationLevel, e);
}
return totalRecords;
}
+ private boolean allPartitionsCaughtUp(KafkaConsumer<byte[], byte[]> consumer, List<TopicPartition> topicPartitions,
+ Map<TopicPartition, Long> endOffsets) {
+ for (TopicPartition tp : topicPartitions) {
+ Long endOffset = endOffsets.get(tp);
+ if (endOffset == null || consumer.position(tp) < endOffset) {
+ return false;
Review Comment:
`consumer.position(tp)` can block (up to `default.api.timeout.ms`) and may exceed the surrounding 60s deadline, making the loop's timeout ineffective. KafkaConsumer provides `position(TopicPartition, Duration)`; using that (or otherwise bounding the position call) would ensure the helper respects the intended timeout and avoids long hangs on metadata/offset fetch issues.
--
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] [Flaky Test] Fix ExactlyOnceKafkaRealtimeClusterIntegrationTest countRecords early termination [pinot]
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #18238:
URL: https://github.com/apache/pinot/pull/18238#issuecomment-4263393121
## [Codecov](https://app.codecov.io/gh/apache/pinot/pull/18238?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 55.28%. Comparing base ([`3cc1902`](https://app.codecov.io/gh/apache/pinot/commit/3cc19023dc8a39cc57c714ebeb5d519d1fb68e62?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`1d211fe`](https://app.codecov.io/gh/apache/pinot/commit/1d211fe8311f038a81c2e51377529ed705b5918f?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
:warning: Report is 8 commits behind head on master.
> :exclamation: There is a different number of reports uploaded between BASE (3cc1902) and HEAD (1d211fe). Click for more details.
>
> <details><summary>HEAD has 24 uploads less than BASE</summary>
>
>| Flag | BASE (3cc1902) | HEAD (1d211fe) |
>|------|------|------|
>|java-21|4|1|
>|unittests1|2|1|
>|unittests|3|1|
>|temurin|7|1|
>|java-11|3|0|
>|unittests2|1|0|
>|integration|4|0|
>|integration2|2|0|
>|integration1|1|0|
>|custom-integration1|1|0|
></details>
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## master #18238 +/- ##
============================================
- Coverage 63.32% 55.28% -8.05%
+ Complexity 1627 837 -790
============================================
Files 3238 2548 -690
Lines 197011 145996 -51015
Branches 30466 23472 -6994
============================================
- Hits 124762 80716 -44046
+ Misses 62244 58306 -3938
+ Partials 10005 6974 -3031
```
| [Flag](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | |
|---|---|---|
| [custom-integration1](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [integration](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [integration1](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [integration2](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [java-11](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [java-21](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `55.28% <ø> (+0.02%)` | :arrow_up: |
| [temurin](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `55.28% <ø> (-8.05%)` | :arrow_down: |
| [unittests](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `55.28% <ø> (-8.04%)` | :arrow_down: |
| [unittests1](https://app.codecov.io/gh/apache/pinot/pull/18238/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `55.28% <ø> (+<0.01%)` | :arrow_up: |
| [unittests2](https://app.codecov.io/gh/apache/pinot/pull/18238/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 Sentry](https://app.codecov.io/gh/apache/pinot/pull/18238?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