artemlivshits commented on code in PR #17402:
URL: https://github.com/apache/kafka/pull/17402#discussion_r1793891014
##########
clients/src/main/java/org/apache/kafka/clients/producer/internals/TransactionManager.java:
##########
@@ -1568,6 +1571,17 @@ public void handleResponse(AbstractResponse response) {
Errors error = endTxnResponse.error();
if (error == Errors.NONE) {
+ // For transaction version 5+, the broker includes the
producerId and producerEpoch in the EndTxnResponse.
+ // KIP-890 Part 2 mandates bumping the epoch after every
transaction. If the epoch overflows,
+ // a new producerId is returned with epoch set to 0.
+ if (isTransactionV2Enabled) {
Review Comment:
My understanding is that downgrade path would work as following:
1. Client may see the that v2 moved back to v1, but continues current
transaction with v2.
2. Brokers will keep receiving new RPC versions until the transaction ends.
3. Client switches to v1 at the beginning of the next transaction and
continues further with v1.
During step 2 one of two things could happen:
a. The broker image still supports new protocol (even though it see v1 as a
TV in the metadata). The broker will honor the new protocol (this behavior is
anyway required for the upgrade path, because a broker may see v2 metadata
update later than the client).
b. The broker is downgraded to an old image. The client should get a
version mismatch error, which would be treated as fatal and require producer
close.
We may need to add a test to test for a case 2b.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
