apache/kafka · error · IllegalArgumentException

Group ID not found: {groupId}

Error message

Group ID not found: {groupId}

What it means

Thrown by ListShareGroupOffsetsResult.partitionsToOffsetInfo(groupId) when the groupId was not among the share groups requested in the original listShareGroupOffsets call. The result object only holds futures for the groups that were requested, so an unknown group is a client-side usage error.

Source

Thrown at clients/src/main/java/org/apache/kafka/clients/admin/ListShareGroupOffsetsResult.java:71

                    try {
                        offsets.put(groupId, future.get());
                    } catch (InterruptedException | ExecutionException e) {
                        // This should be unreachable, since the KafkaFuture#allOf already ensured
                        // that all the futures completed successfully.
                        throw new RuntimeException(e);
                    }
                });
                return offsets;
            });
    }

    /**
     * Return a future which yields a map of topic partitions to offsets for the specified group. If the group doesn't
     * have offset information for a specific partition, the corresponding value in the returned map will be null.
     */
    public KafkaFuture<Map<TopicPartition, SharePartitionOffsetInfo>> partitionsToOffsetInfo(String groupId) {
        if (!futures.containsKey(groupId)) {
            throw new IllegalArgumentException("Group ID not found: " + groupId);
        }
        return futures.get(groupId);
    }
}

View on GitHub (pinned to c31c9215e1)

Solutions

  1. Pass a groupId that is one of the keys used in the listShareGroupOffsets request
  2. Use all() to obtain results for every requested share group instead of guessing an id
  3. Verify the share group id source (config/env) matches the one used to build the request map

Example fix

// before
ListShareGroupOffsetsResult r = admin.listShareGroupOffsets(Map.of("sg1", opts));
r.partitionsToOffsetInfo("sg2"); // throws

// after
r.partitionsToOffsetInfo("sg1");
Defensive patterns

Strategy: validation

Validate before calling

// Track the groupIds given to listShareGroupOffsets and verify before lookup.
Set<String> requestedGroupIds = new HashSet<>(shareGroupOffsetsRequests.keySet());
String groupId = ...;
if (!requestedGroupIds.contains(groupId)) {
    // this share group was not requested; skip
    return;
}
ListShareGroupOffsetsResult result = admin.listShareGroupOffsets(shareGroupOffsetsRequests, options);
result.partitionsToOffsetInfo(groupId).get();

Type guard

static Optional<String> requestedShareGroup(Set<String> requested, String groupId) {
    return groupId != null && requested.contains(groupId) ? Optional.of(groupId) : Optional.empty();
}

Try / catch

try {
    result.partitionsToOffsetInfo(groupId).get();
} catch (IllegalArgumentException e) {
    // groupId was not among the groups passed to listShareGroupOffsets;
    // correct the requested set rather than retry.
    log.warn("Share group {} not in listShareGroupOffsets request", groupId);
}

Prevention

When it happens

Trigger: Calling result.partitionsToOffsetInfo("sg2") after Admin.listShareGroupOffsets was called with a Map whose keys did not include "sg2". Share groups are a newer group type (KIP-932); the same mismatch pattern as consumer groups applies here.

Common situations: Migrating tooling from consumer-group offset listing to share-group offset listing and leaving stale group ids; querying a share group id from config that differs from the one in the request; share group support not enabled on the broker leading to confusion about which ids are valid.

Related errors


AI-assisted analysis of apache/kafka@c31c9215e1 (2026-08-03). Data as JSON: /data/errors/04278c9f6eb9349d.json. Report an issue: GitHub.