hi Ken, there is another inconsistent case for the offset-related APIs. see https://github.com/apache/kafka/pull/19578#discussion_r2068913749
Best, Chia-Ping Chia-Ping Tsai <chia7...@gmail.com> 於 2025年4月30日 週三 下午7:03寫道： > 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 >> >
