MINOR: Simplify PartitionStates update logic by removing unnecessary grouping

[zt52875287]

This patch simplifies the implementation of PartitionStates#update by removing the unnecessary grouping of TopicPartitions by topic. The original logic constructed an intermediate map by topic name, but ultimately only inserted each (TopicPartition, state) pair into the internal LinkedHashMap. This grouping had no effect on the final result.

The updated implementation directly iterates over the input map, improving clarity and reducing overhead.

Additionally, the unit test has been updated to remove reliance on a specific iteration order of partition states. Since both PartitionStates#set and its internal update method accept a Map as input, and standard Java Maps do not guarantee any ordering beyond insertion order (which may not be preserved across implementations), tests should not assume a fixed output order unless explicitly defined by the API.

[FrankYang0529]

The PartitionStates#update(Map<TopicPartition, S>) is only used in PartitionStates#set(Map<TopicPartition, S>). Do you think that it's more clear to move the change to set function directly? For example:

    public void set(Map<TopicPartition, S> partitionToState) {
        map.clear();
        map.putAll(partitionToState);
        updateSize();
    }

[zt52875287]

Thanks for the suggestion. I've updated the code to move the logic directly into the set method as recommended.

[m1a2st]

Thanks for this patch, I have a question, Will this change the order in the map? Will it indirectly affect anything?

[zt52875287]

Thanks for this patch, I have a question, Will this change the order in the map? Will it indirectly affect anything?

I’ve reviewed all call sites of PartitionStates#set() and confirmed that the input Map instances are all HashMap or Java-converted Scala Maps — both of which are unordered by nature.

Specifically:

• SubscriptionState#assignFromUser and assignFromSubscribed both use HashMap
• AbstractFetcherThread#updateFetchOffsetAndMaybeMarkTruncationComplete constructs a Scala Map and calls .asJava, which returns a HashMap-backed implementation.

In the original PartitionStates#update method, although entries were grouped by topic before inserting into the internal LinkedHashMap, the final insertion order was still influenced by the iteration order of the original map. In that sense, the order of the internal map was indirectly related to the input map's order.

The new implementation with putAll() similarly inserts entries based on the input map’s iteration order. It remains dependent on the input map's order — which is non-deterministic in all current usages.

Given that the input maps are all unordered, this change does not affect observable behavior.

[m1a2st]

Thanks @zt52875287 for explaination.