jolshan commented on code in PR #23204:
URL: https://github.com/apache/kafka/pull/23204#discussion_r3883155686
##########
core/src/main/scala/kafka/coordinator/transaction/TransactionCoordinator.scala:
##########
@@ -738,10 +739,17 @@ class TransactionCoordinator(txnConfig: TransactionConfig,
+----------------+-------+---------+-------+---------+
| Empty | PF | EB | PF | ITS |
+----------------+-------+---------+-------+---------+
- | CompleteAbort | NONE | EB | ITS | ITS |
+ | CompleteAbort | NONE | EB | IPE | ITS |
+----------------+-------+---------+-------+---------+
| CompleteCommit | ITS | EB | NONE | ITS |
+----------------+-------+---------+-------+---------+
+
+ CompleteAbort + Commit + Retry returns IPE rather than ITS because the
coordinator may abort an open
+ transaction on its own (e.g. when it exceeds transaction.timeout.ms),
bumping the epoch without the
+ producer's knowledge. A commit that was already in flight when such an
abort completed arrives with the
+ pre-abort epoch and is indistinguishable from a retry. The commit is
guaranteed not to have taken effect,
+ so the recoverable INVALID_PRODUCER_EPOCH is returned, matching the
transaction V1 behavior for this race,
Review Comment:
Yeah, I think there was an informal standard that only produce requests
returned IPE, and all transactional requests return PF. I don't think it
matters a ton in the grand scheme of things, but maybe its easier to keep
things consistent.
My understanding for PF, is just that the producer was fenced, which in the
server-side abort scenario, it is 😄 , but I see how the comment for the error
could be confusing.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
