Hey David, Yes! I meant the metadata version when I said we might have to implement a new IBP. I understand that we don't have to bump the metadata version even if we bump the API version. Is that correct?
On Thu, Oct 16, 2025 at 6:02 AM David Jacot <[email protected]> wrote: > Hi Ritika, > > 1) We don't use IBP anymore, so I'm not sure what you meant. Are you > referring to a new transaction.version or metadata.version? We can rely on > ApiVersions to discover the supported versions and automatically select the > appropriate one. This is what we usually do for inter-broker communication > (e.g. AddPartitionsToTxnManager). Is this perhaps what you meant? > > Thanks, > David > > On Thu, Oct 16, 2025 at 2:58 AM Ritika Reddy <[email protected]> > wrote: > > > Hey David, > > Thanks for the comments! > > 1) The plan was to originally use an API version bump for this, but we > > decided to use a tagged field so that we don't have to implement a new > IBP. > > cc: @Artem Livshits <[email protected]> > > 2) Yes, let me add that to the rejected alternatives section. > > > > > > On Wed, Oct 15, 2025 at 2:49 AM David Jacot <[email protected] > > > > wrote: > > > > > Hi Ritika, > > > > > > Thanks for the KIP. > > > > > > DJ1: What's the reason for using a tagged field? We usually bump the > API > > > version unless there is a good reason not to. This is also > > > backward-compatible. > > > DJ2: In the rejected alternative, could you mention why it is not > > possible > > > to rely on the local `transaction.version` feature flag? > > > > > > Best, > > > David > > > > > > On Wed, Oct 15, 2025 at 9:47 AM Andrew Schofield < > > > [email protected]> > > > wrote: > > > > > > > Hi Ritika, > > > > Thanks for the KIP. I have one question. > > > > > > > > AS1: Does the new WriteTxnMarkers V1 request introduce support for > > > > TV == 2 or TV >= 2? I only ask because the pseudo-code is quite loose > > > > in the checking logic. I would have thought that V1 specifically > > > introduces > > > > TV == 2 and it would take another version bump for this RPC to > support > > > > higher transaction versions. > > > > > > > > Thanks, > > > > Andrew > > > > > > > > > On 15 Oct 2025, at 02:28, Artem Livshits <[email protected] > > > .INVALID> > > > > wrote: > > > > > > > > > > Hi Ritika, > > > > > > > > > > Thanks for the KIP! The proposal makes sense to me. > > > > > > > > > > I have one clarification question, in the rejected alternatives the > > > first > > > > > alternative says "However, its state is cleared after the first > > control > > > > > record is written". Is this the control record or the first batch? > > > > > > > > > > -Artem > > > > > > > > > > On Tue, Oct 14, 2025 at 10:39 AM Ritika Reddy > > > > <[email protected]> > > > > > wrote: > > > > > > > > > >> Hi All, > > > > >> I would like to start a discussion thread for KIP-1228. It's a > > > > relatively > > > > >> simple change and would really help strengthen EOS guarantees in > > > Kafka. > > > > >> KIP Link - > > > > >> > > > > >> > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1228%3A+Add+Transaction+Version+to+WriteTxnMarkersRequest > > > > >> JIRA - https://issues.apache.org/jira/browse/KAFKA-19446 > > > > >> > > > > >> Thanks, > > > > >> Ritika > > > > >> > > > > > > > > > > > > > >
