This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Accepted

Under Discussion thread: here

Discussion Vote thread: here

JIRA:

...

This generation is not currently exposed to any of partition assignors. It will be exposed as part of the assignor.assignonAssignment(...) call in ConsumerCoordinator.java:

// current code
...
assignor.onAssignment(assignment);
...

// revised code
...
assignor.onAssignment(assignment, generation);
...

As a result of above change to the assignor.onAssignment(...) call, a new method is introduced in the interface PartitionAssignor:

default void onAssignment(Assignment assignment, int generation) {
    onAssignment(assignment);
}

The existing onAssignment(...) method will remain to support classes that already implement this interface.

It is expected that classes that implement this interface implement at least one of the two assign(...) methods. A default implementation is provided for this methods to keep assignors that do not make use of group generation (e.g. RangeAssignor and RoundRobinAssignor classes) intact.

Note: During the implementation of this KIP there was a back and forth on whether this generation argument should be an optional argument (i.e. Optional<Integer> ). It turned out that the only edge case where the optional argument would be useful is when an old client makes use of the updated sticky assignor. It was decided that this supposedly rare case would not worth the complexity and the noise that comes with the optional type.

Compatibility, Deprecation, and Migration Plan

The new user data protocol can be implemented in a way that supports backward and forward compatibility.

...