Hello chia, Thanks for suggestion,
I like the hybrid direction. Building on that, I am considering separating this into two distinct strategies rather than a single policy with automatic fallback. One would be by_start_time, which uses the consumer’s local startup timestamp — this is purely client-side and works well for dynamic consumers. The other would be a group-level strategy that relies on server-side timestamps, where the reference point is when the group started. These two strategies would not be mixed — if the group-level strategy is configured and server-side timestamps are not available, the consumer would fail explicitly rather than silently falling back. This keeps the behavior predictable and avoids any hidden switching logic. What do you think about this separation? Best Regards, Jiunn-Yang > Chia-Ping Tsai <[email protected]> 於 2026年3月11日 下午6:59 寫道： > > I am thinking whether we could integrate both approaches. The logic would be > as follows: > > 1. If both server-side timestamps exist, we leverage them to set the policy > (Deterministic & safe for all). > > 2. If they don't, we fall back to using the local startup time as a > best-effort approach. > > 3. However, if it is a static member and the server timestamps are missing, > we throw an exception. > > Thoughts on this hybrid direction? > > On 2026/03/05 11:14:31 黃竣陽 wrote: >> Hello everyone, >> >> I would like to start a discussion on KIP-1282: Prevent data loss during >> partition expansion for dynamically added partitions >> <https://cwiki.apache.org/confluence/x/mIY8G> >> >> This proposal aims to introduce a new auto.offset.reset policy >> by_start_time, anchoring the >> offset reset to the consumer's startup timestamp rather than partition >> discovery time, to prevent >> silent data loss during partition expansion. >> >> Best regards, >> Jiunn-Yang
