Hi, Jose, Thanks for the reply.
We could probably just keep the new HighWatermark field as described in the KIP, but limit it only for KRaft. Also, since HighWatermark is a tagged field, it probably doesn't need to be gated by an MV. Jun On Thu, May 1, 2025 at 7:17 AM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > Hi Jun, > > On Wed, Apr 30, 2025 at 6:28 PM Jun Rao <j...@confluent.io.invalid> wrote: > > Also, KIP-392 > > implemented HWM propagation without adding the HWM field in the fetch > > request. Instead, the leader remembers the last propagated HWM to a > > follower. > > I thought about this when designing the feature, mainly to avoid > having to write a KIP. The issue with using that "last sent > high-watermark" is that that solution assumes that FETCH responses are > reliably received by the client replica. > > > Is that easier to do in KRaft? If so, it's slightly better to > > avoid adding the HWM field in the fetch request since it's irrelevant to > > consumer clients. > > In the long term it may be beneficial to have two replication RPCs. > One for consumers (FETCH) and for brokers (e.g. REPLICATE) and maybe > even another one for KRaft. > > Thanks, > -- > -José >
