...

3) When a record is matched by EofOnRecordEvaluator, SourceReaderBase stops emitting records from this split and informs SplitFetcherManager to stop fetching from this split.

Note that the EofOnRecordEvaluator as well as the SourceReaderBase changes proposed above could also be used by other sources to detect EOF based on de-serialized records.

Compatibility, Deprecation, and Migration Plan

...

This alternative has two disadvantages compared to the proposed approach:
a) It requires backward compatible changes to KafkaSource and thus impose inconvenience on users. This is because we will need to replace KafkaSourceBuilder::setBounded(...) with the new API.

b) Users might want to stop the job based on the offset, de-serialized message, or both. The offset-based criteria should ideally be evaluated before the message is de-serialized for performance-reason; and criteria based on the de-serialized message should be evaluated after the message is de-serialized. Thus these criteria ideally should be evaluated at difference position in the code path. It could be awkward to put these logics in the same class.

c) KafkaStopCursor can not be shared with other source 's implementationtypes because different sources have different raw message formats. For example, KafkaSource uses offset and ConsumerRecord, whereas PulsarSource uses MessageId and Message. In comparison, the EofOnRecordEvaluator proposed in this FLIP (as well as the proposed implementation changes in the SourceReaderBase) could be used by other sources (e.g. PulsarSource) to stop the split detect EOF based on the de-serialized messagerecords.