Kafka CommitFailedException — commit cannot be completed since the group has already rebalanced

What this error actually means

Your consumer was evicted from its group while it was still working, and by the time it tried to commit, the partitions it was committing for belonged to somebody else. The broker rejects the commit because accepting it would let a member that no longer owns a partition move that partition’s offset — which would silently skip records for the member that does own it.

The mechanism is a deadline you probably never set. `poll()` does double duty: it fetches records and it renews the member’s lease. Between two `poll()` calls the group coordinator gives you `max.poll.interval.ms` (default five minutes). If your handler loop spends longer than that processing one batch, the coordinator concludes the member is dead, revokes its partitions, and rebalances. Your thread is alive and healthy — it is simply late.

The important part is what has already happened by the time you see the exception. The records in the uncommitted batch were processed. Another member has now been assigned those partitions from the last committed offset, which is *before* that batch. Those records will be processed again. This exception is therefore not just a commit failure — it is the moment duplicate processing entered your system, and the log line that tells you where to go looking for double-charged, double-shipped, or double-emailed records.

How to diagnose it

grep -E 'poll timeout has expired|Attempt to heartbeat failed|Revoke previously assigned partitions' app.log | tail -40

curl -s localhost:8080/actuator/metrics/kafka.consumer.coordinator.time.between.poll.max

kafka-consumer-groups.sh --bootstrap-server broker:9092 --describe --group orders --state
kafka-consumer-groups.sh --bootstrap-server broker:9092 --describe --group orders --members --verbose

jcmd <pid> GC.heap_info
cat /sys/fs/cgroup/cpu.stat | grep -E "nr_throttled|throttled_usec"

The fix

Bound the work inside one poll, rather than extending the deadline. Set `max.poll.records` to a value where the worst-case per-record latency times the batch size still fits comfortably inside `max.poll.interval.ms`. For a handler whose p99 is 800 ms and a five-minute interval, 100 records leaves a 4x margin; 500 does not.

Put a timeout on every downstream call the handler makes. Without one, a single hung HTTP request makes the poll interval unbounded and no batch size is small enough. This is the fix that actually removes the failure mode; batch sizing only reduces its frequency.

If processing is genuinely long — minutes per record, a job dispatch, a model inference — take it off the poll loop. Hand the record to a bounded executor, and call `pause()` on the assigned partitions while the queue is full and `resume()` when it drains, polling throughout so the lease keeps renewing. This is the supported way to process slowly without lying about liveness.

Make the consumer idempotent, because this exception means you have already replayed records at least once. Key each side effect on the business identifier or on `topic-partition-offset`, and enforce uniqueness in the database rather than checking first and writing after — the check-then-write pattern loses to two consumers running concurrently during a rebalance.

Handle revocation explicitly. In `onPartitionsRevoked`, commit what is finished and abandon what is not; do not attempt to commit a batch for partitions you have been told you no longer own. With `CooperativeStickyAssignor` most partitions survive the rebalance, so the cost of doing this correctly is small.

// Fails whenever one record is slow: the whole batch shares one deadline,
// and the commit at the end is rejected once the group has moved on.
while (true) {
    var records = consumer.poll(Duration.ofMillis(500));   // up to 500 records
    for (var r : records) {
        shipmentClient.create(r.value());                  // no timeout
    }
    consumer.commitSync();
}

// Bounded batch, bounded per-call latency, per-partition commits, and a
// side effect that survives the replay this exception guarantees.
props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 100);
props.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG,
          CooperativeStickyAssignor.class.getName());

while (running) {
    var records = consumer.poll(Duration.ofMillis(500));
    for (var partition : records.partitions()) {
        long lastOffset = -1;
        for (var r : records.records(partition)) {
            shipmentClient.create(r.value());              // client has connect + read timeouts
            lastOffset = r.offset();
        }
        if (lastOffset >= 0) {
            consumer.commitSync(Map.of(partition,
                    new OffsetAndMetadata(lastOffset + 1)));
        }
    }
}

-- the other half of the fix, enforced where concurrency cannot argue with it
CREATE UNIQUE INDEX shipments_order_key ON shipments (order_id);

How to stop it coming back

• Alert on `time-between-poll-max` crossing half of `max.poll.interval.ms`, not on the exception — by the time the exception fires you already have duplicates
• Treat every downstream client used inside a consumer as requiring an explicit connect and read timeout; make it a review rule, because the default in most clients is infinite
• Load-test with full batches. A backlog replay is the realistic worst case and it is trivial to simulate by pausing the consumer for ten minutes
• Keep the group’s partition count and the consumer’s concurrency in a single place, so scaling out does not quietly change per-instance batch arithmetic
• Assert idempotency in tests by delivering the same batch twice and checking row counts, rather than by reasoning about it

FAQ

Related

Other errors engineers hit next to this one

• ERROR: current transaction is aborted, commands ignored until end of transaction block
• ERROR: duplicate key value violates unique constraint
• Deep OFFSET pagination getting slower every page
• ERROR: canceling statement due to lock timeout (ALTER TABLE)
• ERROR: canceling statement due to conflict with recovery
• Threads blocked forever on a ReentrantLock with no deadlock reported
• ThreadLocal value leaking across requests on a pooled thread
• Consumer stuck in Object.wait() with work already in the queue