---
title: "Kafka share consumer acknowledge: accept, release, reject"
description: "One Kafka share consumer acquires three records and acks one of each: accept marks it acked, release makes it available again, reject archives it for good."
url: https://monedula.dev/kafka-simulator/scenarios/acknowledge-accept-release-reject/
---

# Kafka share consumer acknowledge: accept, release, reject

Scenario 11.0.4 · Acknowledge: accept, release, reject. Share groups · Intermediate · about 3 min · Apache Kafka 4.3.

The three share-group acknowledgement outcomes and the record-state transitions each drives - accept→acked, release→available (redelivered), reject→archived (KIP-932).

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4

## What you start with

Explicit acknowledgement gives a share consumer three outcomes per record. A single member acquires all three records in one poll under a long lock, then applies one of each: accept marks a record ACKED (done), release returns it to AVAILABLE for redelivery, and reject ARCHIVES it (skipped, never redelivered).

## Step by step

1. **Cluster ready · idle** (t+0.000s): One partition, one share group (member w1) in EXPLICIT ack mode with a long 5000ms lock so all three records stay held while we apply one of each ack type. Press ▶. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4&t=0)
2. **Three records acquired in-flight** (t+0.750s): First poll (700ms) acquires offsets 0/1/2 (max.poll.records=3), all locked to w1, deliveryCount=1. In explicit mode they stay 'acquired' until acknowledged. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4&t=1)
3. **ACCEPT offset 0 → acked** (t+0.900s): w1 accepts offset 0: state → 'acked'. Accept means processed successfully and terminal - it will never be redelivered, and the share-partition start offset can advance past it. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4&t=2)
4. **RELEASE offset 1 → available** (t+1.100s): w1 releases offset 1: state → 'available'. Release returns the record to the queue un-processed so it can be redelivered (to any member) on a later poll. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4&t=3)
5. **REJECT offset 2 → archived** (t+1.300s): w1 rejects offset 2: state → 'archived'. Reject is terminal like accept but marks the record as NOT to be reprocessed (a poison-pill drop) - it never comes back. Offset 1 is still 'available', waiting for the next poll. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4&t=4)
6. **Released record redelivered** (t+1.500s): The next poll (1400ms) re-acquires offset 1 (deliveryCount=2) - only the RELEASED record returns. Accepted (0) and rejected (2) are both terminal and stay put. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.4&t=5)

## The takeaway

Choosing accept, release, or reject per record is how a share consumer expresses success, retry, and give-up - the per-message control a single classic offset commit cannot give you.

## Configs in this scenario

- [`max.poll.records`](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_max.poll.records): The most records one poll() returns (default 500); a smaller value shortens the processing between two polls, which keeps a group member inside max.poll.interval.ms.

## Further reading

- [KIP-932 on the Apache Kafka wiki](https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka)