hi all, >Also, it would be useful to think through the behavior of ListOffsetsResult.partitionResult(final TopicPartition partition) too.
It seems there are three options: 1. Keep the current behavior - it's inconsistent, as other result classes, such as DeleteRecordsResult, don't have a similar method. 2. Deprecate the current method and add a new method that returns all futures. I prefer this approach as it would align with other result classes. 3. Return null or KafkaFuture<null> - this is a bad idea, so let's not consider it. By the way, DescribeProducersResult#partitionResult(final TopicPartition partition) needs to be considered as well. Best, Chia-Ping Jun Rao <j...@confluent.io.invalid> 於 2025年4月30日 週三 上午6:30寫道： > Hi, Jiunn-Yang, > > Thanks for the KIP. > > It would be useful to think through the consistency with > adminClient.listOffset(). Currently, if the offset for a timestamp doesn't > exist, consumer.offsetsForTimes() returns a null value for that partition > while adminClient.listOffset().all().get() returns a ListOffsetsResultInfo > with -1 as the offset. Should we make the behavior more consistent in the > KIP? Also, it would be useful to think through the behavior > of ListOffsetsResult.partitionResult(final TopicPartition partition) too. > > Jun > > On Fri, Mar 14, 2025 at 4:33 AM 黃竣陽 <s7133...@gmail.com> wrote: > > > Hello everyone, > > > > I would like to start a discussion on KIP-1140: Avoid to return null > value > > in Map from public api of consumer > > <https://cwiki.apache.org/confluence/x/mIuMEw> > > > > This proposal aims to improve the Kafka consumer API by ensuring that the > > Map it returns contains only non-null values, > > aligning with the design philosophy of Java collections. This change > > provides significantly more benefits than drawbacks, > > enhancing API consistency and usability while reducing errors caused by > > developer misuse. > > > > Best Regards, > > Jiunn-Yang >
