[jira] [Created] (KAFKA-21238) Mutating nested sets in consumer assignor input can corrupt coordinator target assignment state

["sanghyeok An (Jira)" <ji...@apache.org>]

sanghyeok An created KAFKA-21238:
------------------------------------

             Summary: Mutating nested sets in consumer assignor input can corrupt coordinator target assignment state
                 Key: KAFKA-21238
                 URL: https://issues.apache.org/jira/browse/KAFKA-21238
             Project: Kafka
          Issue Type: Bug
            Reporter: sanghyeok An
            Assignee: sanghyeok An


*Description*

{{MemberSubscriptionAndAssignmentImpl}} retains an {{Assignment}} that references the coordinator’s existing target assignment. Although {{Assignment}} wraps the outer map with {{{}Collections.unmodifiableMap(){}}}, the nested partition sets remain mutable.

If a custom assignor uses the input assignment as a working data structure and modifies a nested set, it also modifies the coordinator’s existing target assignment before returning the assignment result. 

 

KS also had similar issue https://issues.apache.org/jira/browse/KAFKA-20846 and it had been resolved.

 

*Actual Behavior*

A local reproduction of the Consumer path demonstrated the following:
 * The existing target assignment changes from {{{0, 1}}} to {{{1}}} during assignor execution.
 * {{TargetAssignmentBuilder}} considers the existing assignment and the returned result equal, so it does not generate a target assignment change record for the member.
 * The reverse index still retains the ownership information for partition 0.
 * Rolling back to the snapshot does not restore partition 0 in the nested set.

This can leave the coordinator’s in-memory state, reverse index, and logged state inconsistent.

*Expected Behavior*

The input assignment provided to the assignor should be immutable and isolated from coordinator state. Attempts to modify nested partition sets should be rejected without affecting the coordinator’s existing target assignment.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)