private void maybeMarkPartitionsPendingRevocation() {
        if (protocol != RebalanceProtocol.EAGER) {
            return;
        }

        // When asynchronously committing offsets prior to the revocation of a set of partitions, there will be a
        // window of time between when the offset commit is sent and when it returns and revocation completes. It is
        // possible for pending fetches for these partitions to return during this time, which means the application's
        // position may get ahead of the committed position prior to revocation. This can cause duplicate consumption.
        // To prevent this, we mark the partitions as "pending revocation," which stops the Fetcher from sending new
        // fetches or returning data from previous fetches to the user.
        Set<TopicPartition> partitions = subscriptions.assignedPartitions();
        log.debug("Marking assigned partitions pending for revocation: {}", partitions);
        subscriptions.markPendingRevocation(partitions);
    }
Used by COOPERATIVE rebalance protocol only.

Validate the assignments returned by the assignor such that no owned partitions are going to
be reassigned to a different consumer directly: if the assignor wants to reassign an owned partition,
it must first remove it from the new assignment of the current owner so that it is not assigned to any
member, and then in the next rebalance it can finally reassign those partitions not owned by anyone to consumers.
clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerCoordinator.java