ryerraguntla opened a new pull request, #4401:
URL: https://github.com/apache/iggy/pull/4401
## Which issue does this PR address?
Closes #3548
Relates #3560
## Rationale
`kafka-consumer-groups.sh` and other admin clients learn classic group
membership by sending DescribeGroups and ListGroups. This gateway already
coordinates those groups in memory for join, heartbeat, sync, and leave, and
nothing on the wire would report that state, so those tools could not inspect a
group on this coordinator.
## What changed?
DescribeGroups versions 0-6 and ListGroups versions 0-5 now read that same
in-memory coordinator. A live group is `PreparingRebalance`,
`CompletingRebalance`, or `Stable`. A named group that is not in the map is
`Dead`. Version 6 also returns `GROUP_ID_NOT_FOUND` (69) and `Group {id} not
found.`. Older describe versions return `Dead` with error 0, because a v6
client treats error 0 as a group that exists.
Each member includes its id, its instance id, the subscription metadata of
the selected protocol, and its assignment bytes. `client_id` and `client_host`
stay empty, because the coordinator does not retain the request header's client
id or the connection's peer address. `include_authorized_operations` stays at
the omitted sentinel. There is no group ACL bitfield. ListGroups sets
`group_type` to `classic`. From v4 a state filter, and from v5 a type filter,
keep a group only when the filter is empty or one entry matches,
case-insensitively after trim. A filter value this coordinator does not use
matches nothing, and the response error stays 0.
ListGroups does not expire sessions. Expiry runs on a request that names a
group, and a list names none, so listing must not open rebalances as a side
effect of reading. DescribeGroups ticks each named group once, after the
requested ids are deduped, so a repeated id is one group and one tick. The
describe frame is priced from lengths already stored, before any member
snapshot is copied. If that body would exceed `max_frame_size`, the connection
closes. An oversized ListGroups body closes the same way. The list is priced
before it is encoded, because the request shape guard never sees the groups
that will be written back.
Join rejects a `protocol_type`, a client-supplied `member_id`, or a
`group_instance_id` longer than `i16::MAX`. DescribeGroups v0-v4 and ListGroups
v0-v2 encode those fields as legacy strings, and a longer value cannot be
written back. When the member id is generated, the instance id is the prefix
and 37 bytes are reserved for `-{uuid}`, so the id itself still fits that cap.
A failed DescribeGroups decode closes the connection: the response has no
top-level error field, and an empty group list would look like success. A
failed ListGroups decode returns `INVALID_REQUEST` (42). Groups stay in process
memory only. A restart drops membership. Committed offsets stay in Iggy.
## Local Execution
- Passed:
- `cargo fmt -p iggy-gateway-kafka` (exit 0);
- `cargo test -p iggy-gateway-kafka --lib group::` (79 passed);
- `cargo test -p iggy-gateway-kafka --test consumer_group_tests` (44
passed);
- `cargo clippy -p iggy-gateway-kafka --all-targets -- -D warnings`
## AI Usage
If AI tools were used, please answer:
1. Which tools? Claude
2. Scope of usage? Implementation
3. How did you verify the generated code works correctly?Manual walkthrough,
testing
4. Can you explain every line of the code if asked? Yes
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
