[ 
https://issues.apache.org/jira/browse/KAFKA-16386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838768#comment-17838768
 ] 

Justine Olshan commented on KAFKA-16386:
----------------------------------------

Note: For 3.6, this is only returned in the produce path which treats the 
exception as retriable. The TxnOffsetCommit path is the one that experiences 
the fatal error and is only in 3.7.

> NETWORK_EXCEPTIONs from transaction verification are not translated
> -------------------------------------------------------------------
>
>                 Key: KAFKA-16386
>                 URL: https://issues.apache.org/jira/browse/KAFKA-16386
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 3.6.0, 3.7.0
>            Reporter: Sean Quah
>            Priority: Minor
>             Fix For: 3.8.0
>
>
> KAFKA-14402 
> ([KIP-890|https://cwiki.apache.org/confluence/display/KAFKA/KIP-890%3A+Transactions+Server-Side+Defense])
>  adds verification with the transaction coordinator on Produce and 
> TxnOffsetCommit paths as a defense against hanging transactions. For 
> compatibility with older clients, retriable errors from the verification step 
> are translated to ones already expected and handled by existing clients. When 
> verification was added, we forgot to translate {{NETWORK_EXCEPTION}} s.
> [~dajac] noticed this manifesting as a test failure when 
> tests/kafkatest/tests/core/transactions_test.py was run with an older client 
> (prior to the fix for KAFKA-16122):
> {quote}
> {{NETWORK_EXCEPTION}} is indeed returned as a partition error. The 
> {{TransactionManager.TxnOffsetCommitHandler}} considers it as a fatal error 
> so it transitions to the fatal state.
> It seems that there are two cases where the server could return it: (1) When 
> the verification request times out or its connections is cut; or (2) in 
> {{AddPartitionsToTxnManager.addTxnData}} where we say that we use it because 
> we want a retriable error.
> {quote}
> The first case was triggered as part of the test. The second case happens 
> when there is already a verification request ({{AddPartitionsToTxn}}) in 
> flight with the same epoch and we want clients to try again when we're not 
> busy.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to