...

While existing APIs remain unchanged a new API DeleteGroups is introduced to remove offsets of the given group(s) from the internal offset cache. A deleteGroups() functionality will also be introduced in AdminClient API.

Proposed Changes

A new API is introduced for deleting consumer groups:

...

• 0: None
• 15: COORDINATOR_NOT_AVAILABLE
• 24: INVALID_GROUP_ID
• 30: GROUP_AUTHORIZATION_FAILED
• ??: NON_EMPTY_GROUP

Note that the error code NON_EMPTY_GROUP is an error code introduced by this KIP to address the case where the group is not empty (i.e. group state is not Empty) and cannot be deleted. 

Similar to how the consumer group command line tool supports describing a single group at a time, the deletion functionality will be implemented the same way (deleting one group at a time). The protocol and the corresponding AdminClient API, however, support deleting multiple groups in one request. The new AdminClient API signature in kafka.admin.AdminClient would be like this:

def deleteConsumerGroups(groupIds: List[String]): DeleteGroupsResult

DeleteGroupsResult will include the top level as well as per group error codes. It will be derived from a DeleteGroupsResponse class that will be created in org.apache.kafka.common.requests to fully capture the outcome of a DeleteGroups API call from the broker.

Compatibility, Deprecation, and Migration Plan

The changes proposed by this KIP apply to the new Java-based consumer only, and are backward compatible because the suggested API does not already exist. New clients that work with older brokers will not be able to make use of this new API.

...

1. Using the newly introduced offset reset functionality of the consumer group command tool by injecting a retention_time of 0. : This alternative was rejected in favor of KIP-211, that aims at removing the retention_time field from the OffsetCommit API.
2. Exposing the group deletion functionality in org.apache.kafka.clients.admin.AdminClient: This was left as a future work as no group-related functionality has been implemented in AdminClient yet.
3. Providing the functionality to delete individual offsets: This was also left as a potential future work to keep the initial implementation simple. If, in the future, it turns out that per-partition offset reset is not sufficient and there is a need to delete individual offsets, it can be proposed and implemented in its own KIP.