[
https://issues.apache.org/jira/browse/KAFKA-15657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17777524#comment-17777524
]
Justine Olshan commented on KAFKA-15657:
----------------------------------------
Hey Travis. INVALID_TXN_STATE likely indicates there was a race condition or a
bug in the client. In this case, the transaction should abort. This is part of
the work of KIP-890.
I wonder if there is a bug in the client that caused hanging (or late messages
getting through) before and it is just being caught now.
If you want to disable transaction verification, you can by setting
transaction.partition.verification.enable to false in your server config files.
> Unexpected errors when producing transactionally in 3.6
> -------------------------------------------------------
>
> Key: KAFKA-15657
> URL: https://issues.apache.org/jira/browse/KAFKA-15657
> Project: Kafka
> Issue Type: Bug
> Components: producer
> Affects Versions: 3.6.0
> Reporter: Travis Bischel
> Priority: Major
>
> In loop-testing the franz-go client, I am frequently receiving INVALID_RECORD
> (which I created a separate issue for), and INVALID_TXN_STATE and
> UNKNOWN_SERVER_ERROR.
> INVALID_TXN_STATE is being returned even though the partitions have been
> added to the transaction (AddPartitionsToTxn). Nothing about the code has
> changed between 3.5 and 3.6, and I have loop-integration-tested this code
> against 3.5 thousands of times. 3.6 is newly - and always - returning
> INVALID_TXN_STATE. If I change the code to retry on INVALID_TXN_STATE, I
> eventually quickly (always) receive UNKNOWN_SERVER_ERROR. In looking at the
> broker logs, the broker indicates that sequence numbers are out of order -
> but (a) I am repeating requests that were in order (so something on the
> broker got a little haywire maybe? or maybe this is due to me ignoring
> invalid_txn_state?), _and_ I am not receiving OUT_OF_ORDER_SEQUENCE_NUMBER, I
> am receiving UNKNOWN_SERVER_ERROR.
> I think the main problem is the client unexpectedly receiving
> INVALID_TXN_STATE, but a second problem here is that OOOSN is being mapped to
> USE on return for some reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
