Hi Jiunn, Thank you for this great kip. Good to know about the gap.
mb-0 - why a new v2 version bump for RequestPartitionAges field. Can a tagged field (for ex: on response, PartitionAges on TopicPartitions) be used here and avoid version bump? mb-1 - For the new config, is there a recommended value or a ConfigDef validator? Probably it should based on the metadata.max.age.ms ? Sizing instructions can be part of javadocs I guess. mb-2 - (minor) As there are no changes to Kafka Streams, would it be better to add this new config auto.offset.reset.latest.max.age to the StreamsConfig block list (NON_CONFIGURABLE_CONSUMER_DEFAULT_CONFIGS) for a clear warning, incase users configure it? This is the most familiar consumer config and users might easily mistakenly configure it. Or may be it's not worth it to add. mb-3 - (minor) The phrasing "the consumer falls back to earliest" reads as if the config were being changed per-partition which isn't supported. May be rephrasing to something like "consumer resolves the initial position to start offset for that partition" as if earliest was applied to that partition only and auto.offset.reset config is unchanged. Thanks, Murali On Tue, Apr 28, 2026 at 2:48 PM 黃竣陽 <[email protected]> wrote: > Hi chia, > > I have updated the KIP to include this change. > > Best Regards, > Jiunn-Yang > > > Chia-Ping Tsai <[email protected]> 於 2026年4月28日 晚上8:03 寫道： > > > > hi Jiunn-Yang > > > > chia_0: Should we expose the partition creation time via the Admin API? > I assume it would be valuable for users to diagnose and troubleshoot the > behavior of auto.offset.reset.latest.max.age > > > > Best, > > Chia-Ping > > > > On 2026/04/28 10:47:58 黃竣陽 wrote: > >> Hello everyone, > >> > >> I would like to start a discussion on KIP-1327 Prevent Hot Data Loss on > Partition Expansion for Latest Policy > >> <https://cwiki.apache.org/confluence/x/KY4mGQ> > >> > >> This proposal aims to introduces auto.offset.reset.latest.max.age, a > consumer config that lets the > >> latest reset policy distinguish newly expanded (hot) partitions from > long-existing (cold) ones. Partitions > >> younger than the configured threshold automatically fall back to > earliest, preventing silent data loss > >> during topic expansion without forcing a full historical reprocess. > >> > >> Best regards, > >> Jiunn-Yang > >
