[ https://issues.apache.org/jira/browse/KAFKA-13033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luke Chen updated KAFKA-13033: ------------------------------ Description: In KIP-699, we add some handler to handle different types of operation. In the `handleError`, we didn't make the `COORDINATOR_NOT_AVAILABLE` as unmapped, to do a re-lookup. In [DescribeTransactionsHandler|https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/admin/internals/DescribeTransactionsHandler.java#L172-L186], there's already explained by [~hachikuji] why `COORDINATOR_NOT_AVAILABLE` and `NOT_COORDINATOR` should be listed in unmapped, and `COORDINATOR_LOAD_IN_PROGRESS` should not. {code:java} case COORDINATOR_LOAD_IN_PROGRESS: // If the coordinator is in the middle of loading, then we just need to retry log.debug("DescribeTransactions request for transactionalId `{}` failed because the " + "coordinator is still in the process of loading state. Will retry", transactionalIdKey.idValue); break; case NOT_COORDINATOR: case COORDINATOR_NOT_AVAILABLE: // If the coordinator is unavailable or there was a coordinator change, then we unmap // the key so that we retry the `FindCoordinator` request unmapped.add(transactionalIdKey); log.debug("DescribeTransactions request for transactionalId `{}` returned error {}. Will attempt " + "to find the coordinator again and retry", transactionalIdKey.idValue, error); break; {code} We should be consistent with it. Fix it, add logs and comments, and also update the tests. was: In KIP-699, we add some handler to handle different types of operation. In the `handleError`, we didn't make the `COORDINATOR_NOT_AVAILABLE` as unmapped, to do a re-lookup. In [DescribeTransactionsHandler|#L172-L186],], there's already explained by [~hachikuji] why `COORDINATOR_NOT_AVAILABLE` and `NOT_COORDINATOR` should be listed in unmapped, and `COORDINATOR_LOAD_IN_PROGRESS` should not. {code:java} case COORDINATOR_LOAD_IN_PROGRESS: // If the coordinator is in the middle of loading, then we just need to retry log.debug("DescribeTransactions request for transactionalId `{}` failed because the " + "coordinator is still in the process of loading state. Will retry", transactionalIdKey.idValue); break; case NOT_COORDINATOR: case COORDINATOR_NOT_AVAILABLE: // If the coordinator is unavailable or there was a coordinator change, then we unmap // the key so that we retry the `FindCoordinator` request unmapped.add(transactionalIdKey); log.debug("DescribeTransactions request for transactionalId `{}` returned error {}. Will attempt " + "to find the coordinator again and retry", transactionalIdKey.idValue, error); break; {code} We should be consistent with it. Fix it, add logs and comments, and also update the tests. > coordinator not available error should cause add into unmap list to do a new > lookup > ----------------------------------------------------------------------------------- > > Key: KAFKA-13033 > URL: https://issues.apache.org/jira/browse/KAFKA-13033 > Project: Kafka > Issue Type: Bug > Affects Versions: 3.0.0 > Reporter: Luke Chen > Assignee: Luke Chen > Priority: Major > > In KIP-699, we add some handler to handle different types of operation. In > the `handleError`, we didn't make the `COORDINATOR_NOT_AVAILABLE` as > unmapped, to do a re-lookup. In > [DescribeTransactionsHandler|https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/admin/internals/DescribeTransactionsHandler.java#L172-L186], > there's already explained by [~hachikuji] why `COORDINATOR_NOT_AVAILABLE` > and `NOT_COORDINATOR` should be listed in unmapped, and > `COORDINATOR_LOAD_IN_PROGRESS` should not. > > {code:java} > case COORDINATOR_LOAD_IN_PROGRESS: > // If the coordinator is in the middle of loading, then we just need to > retry > log.debug("DescribeTransactions request for transactionalId `{}` failed > because the " + > "coordinator is still in the process of loading state. Will > retry", > transactionalIdKey.idValue); > break; > case NOT_COORDINATOR: > case COORDINATOR_NOT_AVAILABLE: > // If the coordinator is unavailable or there was a coordinator change, > then we unmap > // the key so that we retry the `FindCoordinator` request > unmapped.add(transactionalIdKey); > log.debug("DescribeTransactions request for transactionalId `{}` returned > error {}. Will attempt " + > "to find the coordinator again and retry", > transactionalIdKey.idValue, error); > break; > {code} > We should be consistent with it. Fix it, add logs and comments, and also > update the tests. > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)