redpanda-data / redpanda-data/console
Kafka node offline causes consumer group queries to fail entirely
Open
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 4.3k
- Forks
- 432
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 40
Description
Description
When a single Kafka broker/node goes offline, querying consumer group information results in complete failure instead of partial degradation or graceful handling.
Steps to Reproduce
- Set up a Kafka cluster with multiple brokers.
- Create a topic and a consumer group consuming from it.
- Shut down one Kafka broker (simulate node failure).
- Run consumer group query commands
Expected Behavior
- Consumer group queries should still return available information from remaining brokers.
Actual Behavior
- All consumer group queries fail when one broker is offline.
{
"statusCode": 404,
"message": "Failed to get consumer group lags: failed to list end offsets for topics: request ListOffsets has 1 separate shard errors, first: LISTENER_NOT_FOUND: There is no listener on the leader broker that matches the listener on which metadata request was processed."
}
Impact
- Affects observability and troubleshooting during partial cluster failures.
- Makes it difficult to monitor lag and consumer status in degraded scenarios.
Environment
- Kafka version: 2.x / 3.x
- Deployment mode: Kubernetes
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or code entry points. Reproduce the failure with a multi-broker Kafka cluster, a consumer group, and one broker offline, then trace the consumer group query path. Done means queries return available information or handle the degraded cluster gracefully instead of failing entirely.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kafka, kubernetes
- Domain
- backend-api-design, distributed-systems, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100