Skip to content
Kafka Is Fun
ConsumerConsumers

CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member

Checked against Kafka 4.2 · Oct 2026Community draft, not yet reviewed by a Kafka specialist

What it means

The consumer tried to commit offsets after the group had already rebalanced and moved its partitions to another member. The Javadoc says this can happen when a group rebalance completes before the commit could be applied, and that the commit cannot generally be retried because some partitions may already be assigned to another member. The full message adds that the time between calls to poll() was longer than max.poll.interval.ms, which typically implies the poll loop is spending too much time on message processing.

Quick answer

Your processing between two calls to poll() was longer than max.poll.interval.ms (300000 ms, five minutes, by default). The exception message itself suggests either increasing max.poll.interval.ms or reducing the batch size with max.poll.records (500 by default).

Likely causes, most common first

  1. The poll loop takes longer than max.poll.interval.ms

    How to confirm

    Time one loop iteration, from poll() returning to the next poll() call. If you do not call poll() at least as often as max.poll.interval.ms, the client leaves the group, and the KafkaConsumer Javadoc lists a CommitFailedException as a result.

    confirm
    # consumer configuration
max.poll.records=100
max.poll.interval.ms=300000

    Fix

    Lower max.poll.records so a batch finishes in time, or raise max.poll.interval.ms to give the consumer more time. The Javadoc's recommended way to handle long processing is to move it to another thread and pause() the partitions until it finishes, so poll() keeps being called.

  2. The member was removed because heartbeats stopped

    How to confirm

    The broker removes a client from the group, and starts a rebalance, if it receives no heartbeats before session.timeout.ms (45000 ms by default). heartbeat.interval.ms (3000 ms by default) should typically be no higher than a third of the session timeout. This applies to the classic protocol only.

    Fix

    Find out why the consumer stopped sending heartbeats. For process restarts, the documentation says a static member (group.instance.id) combined with a larger session timeout avoids rebalances caused by transient unavailability.

  3. The group rebalanced for another reason and the commit came too late

    How to confirm

    A member joined or left, and the commit for the revoked partitions arrived after the rebalance had finished. On the new consumer protocol (group.protocol=consumer) the exception text is different: "OffsetCommit failed with stale member epoch."

    Fix

    The ConsumerRebalanceListener Javadoc recommends committing offsets in onPartitionsRevoked to prevent duplicate data. With cooperative rebalancing, onPartitionsRevoked is called only with the partitions being revoked; with eager rebalancing it is called with all assigned partitions.

See it happen

Trigger a consumer rebalance

Opens the simulator with this exercise already running. About 5 minutes.

Reproduce in the simulator

Sources

Every claim above comes from these Apache pages, as of Kafka 4.2. If a page does not say it, this entry does not.

Was this helpful?

Report an issue (opens GitHub in a new tab)

Back to all errors