redpanda-data / redpanda-data/console

Kafka node offline causes consumer group queries to fail entirely

Open
#2,327 0 comments 0 reactions 0 assignees View on GitHub

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

  1. Set up a Kafka cluster with multiple brokers.
  2. Create a topic and a consumer group consuming from it.
  3. Shut down one Kafka broker (simulate node failure).
  4. 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.
Image
{
    "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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.