Copilot commented on code in PR #19161:
URL: https://github.com/apache/pinot/pull/19161#discussion_r3738658471
##########
pinot-plugins/pinot-stream-ingestion/pinot-kafka-4.0/src/main/java/org/apache/pinot/plugin/stream/kafka40/KafkaPartitionLevelConsumer.java:
##########
@@ -166,15 +166,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;
Review Comment:
`poll()` has already been allowed to consume the entire `timeoutMs`, but
this second broker call receives a fresh full timeout. On the gap path,
`fetchMessages` can therefore block for almost twice the caller's timeout,
violating the `PartitionGroupConsumer.fetchMessages` contract that it return
within that timeout (`PartitionGroupConsumer.java:43-50`). Track a deadline
before polling and pass only the remaining budget here (or skip this
best-effort lookup once the budget is exhausted); add a test that verifies the
second call cannot extend the overall timeout.
##########
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;
Review Comment:
`poll()` has already been allowed to consume the entire `timeoutMs`, but
this second broker call receives a fresh full timeout. On the gap path,
`fetchMessages` can therefore block for almost twice the caller's timeout,
violating the `PartitionGroupConsumer.fetchMessages` contract that it return
within that timeout (`PartitionGroupConsumer.java:43-50`). Track a deadline
before polling and pass only the remaining budget here (or skip this
best-effort lookup once the budget is exhausted); add a test that verifies the
second call cannot extend the overall timeout.
--
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]
