Page History

...

• All non-assignment metadata as defined in the ConsumerGroupHeartbeatRequest such as the group ID, member ID, member epoch, instance ID, rack ID and rebalance timeout.

• The currently assigned active, standby and warm-up tasks. Each task is identified by a subtopology ID (which can be an arbitrary string in protocol for future extensibility, even though subtopologies are currently numbered) and a partition number.

• The process ID to identify multiple members running in the same process (i.e. the same Streams client).

• The user-defined endpoint to be used for running interactive queries.

• Topology metadata needed for creating internal topics and computing the assignment.

• The topology epoch, which is defined by the client, and will be 0 1 normally. The epoch can be bumped by the client to deploy a new version of the topology metadata.

• For each task, the current sum of task changelog offsets and task changelog end offsets. These are used to determine whether a warm-up task is below acceptable.recovery.lag and can be used to optimize the assignment in the assignor. For more details on these offsets see "Cumulative task changelog offsets and task changelog end offsets" section below

• A flag to request shutdown of the whole application (only if the member epoch is the group leave epoch).

...

To avoid unintential topology updates or rollbacks, updating the broker-side topology after it has been initialized for a group requires bumping the client-side configuration topology.epoch, which defaults to 01. By default, whenever a Streams member joins the group with a topology that is different from the current topology of the streams group, and the topology epoch is not bumped, the group coordinator will respond with an error, indicating that the member is incorrectly updating the broker-side topology. 

...

...