[KAFKA-13033] coordinator not available error should cause add into unmap list to do a new lookup

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 3.0.0
• Fix Version/s: 3.0.0
• Assignee: Luke Chen
• Reporter: Luke Chen
• Reviewer: David Jacot
• Created: 04/Jul/21 10:14
• Updated: 22/Jul/21 10:59
• Resolved: 16/Jul/21 08:01

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, 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.

 

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;

We should be consistent with it. Fix it, add logs and comments, and also update the tests.

 

 

 

Issue Links

• links to: GitHub Pull Request #10973

Sub-Tasks

• update for DeleteConsumerGroupOffsetsHandler: Resolved
• refactor DeleteConsumerGroupsHandler: Resolved
• refactor DescribeConsumerGroupsHandler: Resolved
• refactor ListConsumerGroupOffsetsHandler: Resolved
• refactor RemoveMembersFromConsumerGroupHandler: Resolved