hi Jun > It seems that consumer.committed() has the same behavior. If you pass in a non-existing partition, it returns a map with a null value. So, if we want to make a change, it would be useful to make it consistent too.
yes, both consumers have same behavior. For another, `listStreamsGroupOffsets` and `listShareGroupOffsets` also add null value. They are not in production, but maybe we should keep the behavior for consistency. Best, Chia-Ping Jun Rao <j...@confluent.io.invalid> 於 2025年5月1日 週四 上午2:38寫道： > Hi, Chia-Ping, > > It seems that consumer.committed() has the same behavior. If you pass in a > non-existing partition, it returns a map with a null value. So, if we want > to make a change, it would be useful to make it consistent too. > > Thanks, > > Jun > > On Wed, Apr 30, 2025 at 9:05 AM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > 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 > > >> > > > > > >
