Hi Raman, Thank you for the questions. Given that the primary effect of setting enable2pc flag is disabling timeout, it makes sense to make enable2pc have similar behavior w.r.t. when it can be set.
One clarification about the Ongoing case -- the current (pre-KIP-939) behavior is to abort ongoing transaction and let the client retry (eventually getting into CompleteAbort state), so even though transaction timeout is not changed when actually hitting the ongoing transaction, the new timeout value would take effect before the call completes to the caller. So if we look from the caller perspective, the transaction timeout is set whenever the InitProducerId functionality is used. -Artem On Wed, Oct 4, 2023 at 8:58 PM Raman Verma <raman.x.ve...@gmail.com> wrote: > Hello Artem, > > Now that `InitProducerIdRequest` will have an extra parameter (enable2PC), > can the client change the value of this parameter during an ongoing > transaction. > > Here is how the transaction coordinator responds to InitProducerId requests > according > to the current transaction's state. > > - Empty | CompleteAbort | CompleteCommit > Bump epoch and move to Empty state. Accept any changes from incoming > InitProducerId > request like transactionTimeoutMs > > - Ongoing > Bump epoch and move to PrepareEpochFence state. Transaction time out is not > changed. > > - PrepareAbort | PrepareCommit > No changes internally. Return Concurrent transactions error to the client. > > I guess we should allow the same behavior for mutating enable2PC flag > under these conditions as for transaction timeout value. >
