rreddy-22 commented on code in PR #15152:
URL: https://github.com/apache/kafka/pull/15152#discussion_r1459544349


##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupMetadataManager.java:
##########
@@ -452,21 +453,39 @@ public Group group(String groupId, long committedOffset) 
throws GroupIdNotFoundE
     /**
      * Get the Group List.
      *
-     * @param statesFilter The states of the groups we want to list.
-     *                     If empty all groups are returned with their state.
-     * @param committedOffset A specified committed offset corresponding to 
this shard
+     * @param statesFilter      The states of the groups we want to list.
+     *                          If empty, all groups are returned with their 
state.
+     * @param typesFilter       The types of the groups we want to list.
+     *                          If empty, all groups are returned with their 
type.
+     * @param committedOffset   A specified committed offset corresponding to 
this shard.
      *
      * @return A list containing the ListGroupsResponseData.ListedGroup
      */
+    public List<ListGroupsResponseData.ListedGroup> listGroups(
+        Set<String> statesFilter,
+        Set<String> typesFilter,
+        long committedOffset
+    ) {
+        // Convert typesFilter to lowercase to make the filter 
case-insensitive.
+        Set<String> lowerCaseTypesFilter = typesFilter.stream()
+            .map(String::toLowerCase)
+            .collect(Collectors.toCollection(HashSet::new));
+
+        Predicate<Group> combinedFilter = group -> {
+            boolean stateCheck = statesFilter.isEmpty() || 
statesFilter.contains(group.stateAsString(committedOffset));
+            boolean typeCheck = lowerCaseTypesFilter.isEmpty() ||
+                
lowerCaseTypesFilter.contains(group.type().toString().toLowerCase());

Review Comment:
   I was also under the impression that case insensitive meant that as long as 
the word spells the correct type we don't care what the cases of the letters 
are? So currently if someone were to type "cLaSsic" that would still be valid. 
If we want to strictly allow only "Classic" and "classic" we would need to 
probably add both for each type to the enum itself. Lmk what you think?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to