swaminathanmanish commented on code in PR #19161:
URL: https://github.com/apache/pinot/pull/19161#discussion_r3749422082


##########
pinot-plugins/pinot-stream-ingestion/pinot-kafka-3.0/src/main/java/org/apache/pinot/plugin/stream/kafka30/KafkaPartitionLevelConsumer.java:
##########
@@ -165,15 +165,36 @@ public synchronized KafkaMessageBatch 
fetchMessages(StreamPartitionMsgOffset sta
       }
     }
     long offsetOfNextBatch = _nextReadOffset;
-    // For read_uncommitted (the default), a non-contiguous returned batch 
implies data
-    // loss (records dropped before being read). For read_committed the offset 
gap is
-    // expected because the broker filters aborted transactional records, so 
we don't flag
-    // it as data loss.
-    boolean hasDataLoss = !_isReadCommitted && firstOffset > startOffset;
+    // A gap between the requested startOffset and the first returned offset 
does NOT by itself
+    // imply data loss. Transactional producers write commit/abort control 
records that occupy
+    // offsets but are never delivered to the consumer (even under 
read_uncommitted), so a
+    // contiguous stream of user records legitimately has offset gaps. Real 
data loss only
+    // happens when the requested startOffset is below the log's start offset, 
i.e. the broker
+    // has already deleted (via retention or truncation) records at or after 
startOffset. For
+    // read_committed we never flag loss because aborted-record gaps are 
always expected.
+    boolean hasDataLoss = false;
+    if (!_isReadCommitted && firstOffset > startOffset) {
+      hasDataLoss = getLogStartOffset(timeoutMs) > startOffset;
+    }
     return new KafkaMessageBatch(filteredRecords, records.size(), 
offsetOfNextBatch, firstOffset, lastMessageMetadata,
         hasDataLoss, batchSizeInBytes);
   }
 
+  /// Returns the log start (earliest available) offset for the partition, 
bounded by the same
+  /// timeout as [#poll]. Returns [Long#MIN_VALUE] when it cannot be 
determined so the caller
+  /// treats an offset gap as expected (no data loss) rather than raising a 
false positive.
+  private long getLogStartOffset(int timeoutMs) {
+    try {
+      return _consumer.beginningOffsets(List.of(_topicPartition), 
Duration.ofMillis(timeoutMs))
+          .getOrDefault(_topicPartition, Long.MIN_VALUE);
+    } catch (Exception e) {
+      if (LOGGER.isDebugEnabled()) {
+        LOGGER.debug("Failed to read log start offset for {}", 
_topicPartition, e);

Review Comment:
   Made this a warn msg. Hope it does not flood the log or we need a rate 
limiter. 



-- 
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]

Reply via email to