This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Under Discussion

Discussion thread: here

JIRA: [KAFKA-19883]()

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

1 Motivation

In the current KIP-932 implementation, Share Group acknowledgments are immediate and irrevocable.

If a processing framework (Flink, Spark, etc.) crashes after acknowledging a record but before committing its own state, that record is lost.

Current State: ACKNOWLEDGED is a terminal state; there is no way to revert to AVAILABLE for redelivery.
The Risk: Permanent data loss during processing failures.

The Goal: Atomic "Read-Process-Write"

Enable Exactly-Once Semantics (EOS) by making acknowledgments part of a Kafka transaction. Either the output is produced AND the source record is acknowledged, or neither happens.

1.1 Background: Share Groups

Current State Machine:

AVAILABLE: Ready for delivery.
ACQUIRED: Locked by a consumer.
ACKNOWLEDGED / ARCHIVED: Terminal states; records are never redelivered.
AVAILABLE (Released): Returned to the pool for redelivery.

Current Acknowledgment Modes:

Implicit: Automatic ack on the subsequent poll().
Explicit: Manual ack via acknowledge(record, type) followed by commitSync()

1.2 Why Existing Consumer-Group Exactly-Once Doesn't Apply

Traditional Consumer Groups rely on replayability, which Share Groups lack:

Consumer Groups: Frameworks like Flink save offsets in their own state. On failure, they use seek(offset) to replay data. In this model, Kafka offset commits are "cosmetic" (non-critical) because Flink is the source of truth.
Share Groups: There is no seek() functionality. The broker manages delivery; once a record is acknowledged, it is removed from the delivery pipeline.
The Conflict: Because records cannot be replayed, the acknowledgment itself must be the transactional boundary. It must stay "pending" until the entire processing transaction is confirmed.

1.3 Existing Pattern: `sendOffsetsToTransaction()`

Feature	Traditional Consumer Groups	Share Groups (Proposal)
Commit Method	`sendOffsetsToTransaction()`	`sendShareAcksToTransaction()`
Storage	`__consumer_offsets`	`__share_group_state`
Atomic Fate	Records + Offsets commit together	Records + Acknowledgment commit together
On Abort	Consumer re-reads from old offset	Broker reverts records to `AVAILABLE`

2. Use Cases

2.1 Consume-Transform-Produce (CTP)

An application reads from a share group, transforms records, and produces output to another Kafka topic. Both output and acknowledgments must commit atomically.

producer.beginTransaction();

ConsumerRecords<K,V> records = shareConsumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<K,V> record : records) {
    ProducerRecord<K,V> output = transform(record);
    producer.send(output);
}

// Bind share acks to this transaction (NEW API)
producer.sendShareAcksToTransaction(
    ShareAcknowledgements.fromRecords(records, AcknowledgeType.ACCEPT),
    shareConsumer.groupMetadata()
);

producer.commitTransaction();
// Output records AND share acks commit atomically

2.2 Flink / Spark Source (No Producer)

A streaming framework reads from a share group as a source. There is no Kafka producer in the pipeline — the output may go to a database, filesystem, or another system. The framework needs to commit share acks transactionally, coordinated with its own checkpointing.

TransactionalShareAcknowledger acknowledger = new TransactionalShareAcknowledger(props);
acknowledger.initTransactions();

// On checkpoint complete:
acknowledger.commitAcknowledgements(bufferedAcks, shareGroupId);
// Internally: beginTransaction → sendShareAcksToTransaction → commitTransaction

2.3 Flink End-to-End Exactly-Once (Source + Sink)

When a Flink pipeline reads from a Kafka share group and writes to a Kafka sink topic, we achieve end-to-end exactly-once by binding both sink output and source acknowledgments to the same Kafka transaction:

Checkpoint lifecycle:
  prepareCommit()              → flush sink records, pre-commit Kafka txn
                               → include share acks in the same transaction
  snapshotState()              → save txn metadata + buffered acks
  notifyCheckpointComplete()   → commitTransaction() (acks + output atomically)
  On failure                   → abortTransaction() (acks + output both rolled back)

3 Public Interfaces

New API	Mirrors	Why Needed
`sendShareAcksToTransaction()`	`sendOffsetsToTransaction()`	Acks are stored in `__share_group_state`, not `__consumer_offsets`
`AddShareAcksToTxnRequest`	`AddOffsetsToTxnRequest`	Transaction coordinator must track `__share_group_state` partitions
`TxnShareAcknowledgeRequest`	`TxnOffsetCommitRequest`	Ack semantics are per‑record state, not per‑offset

3.1 KafkaProducer API Addition

// In org.apache.kafka.clients.producer.KafkaProducer:

/**
 * Sends share-group acknowledgments as part of the current transaction.
 * Mirrors sendOffsetsToTransaction() but writes to __share_group_state
 * instead of __consumer_offsets.
 *
 * @param acknowledgements Map of TopicPartition to list of acknowledgment batches
 * @param groupMetadata    The share group metadata (group ID, member ID, generation)
 * @throws IllegalStateException if no transaction is in progress
 * @throws ProducerFencedException if the producer is fenced
 */
public void sendShareAcksToTransaction(
    Map<TopicPartition, ShareAcknowledgements> acknowledgements,
    ShareGroupMetadata groupMetadata
) throws ProducerFencedException;

This mirrors sendOffsetsToTransaction(). The reason a new method is needed (instead of reusing the existing one) is that:

Different storage topic: acks go to __share_group_state, not __consumer_offsets.
Different coordinator: the ShareCoordinator handles ack persistence, not GroupCoordinator.
Different semantics: acks are per-record state transitions, not per-partition offsets.

3.2 TransactionalShareAcknowledger (Standalone)

For frameworks that do not use a KafkaProducer in the pipeline:

public class TransactionalShareAcknowledger implements Closeable {

    public TransactionalShareAcknowledger(Properties config);

    /** Initialize the internal transactional producer. Call once. */
    public void initTransactions();

    /**
     * Atomically commit share acknowledgments.
     * Internally executes: beginTransaction → sendShareAcksToTransaction → commitTransaction.
     * This is NOT a single RPC. It orchestrates the standard 2PC protocol.
     */
    public void commitAcknowledgements(
        Map<TopicPartition, ShareAcknowledgements> acks,
        String groupId
    );

    /** Abort any in-progress transactional acknowledgment. */
    public void abortAcknowledgements();

    public void close();

}

Clarification: commitAcknowledgements() is a convenience wrapper. It internally calls three operations in sequence:

beginTransaction()
sendShareAcksToTransaction(acks, groupMetadata)
commitTransaction()

It does NOT introduce a new single-RPC path. It uses the standard 2PC protocol.

3.3 ShareGroupMetadata

public class ShareGroupMetadata {
    private final String groupId;
    private final String memberId;
    private final int generationId;
    // constructor, getters

}

3.4 ShareAcknowledgements

public class ShareAcknowledgements {
    private final List<ShareAcknowledgementBatch> batches;

    public static ShareAcknowledgements fromRecords(
        ConsumerRecords<?, ?> records, AcknowledgeType type);

    // Each batch: firstOffset, lastOffset, acknowledgeType

}

3.5 New Metrics

Metric Name	Type	Description
`share-transaction-active`	Gauge	Number of active share-group transactions
`share-transaction-prepare-time-ms`	Histogram	Time to prepare share ack transaction
`share-transaction-commit-time-ms`	Histogram	Time to commit share ack transaction
`share-transaction-abort-total`	Counter	Total aborted share ack transactions
`share-transaction-timeout-total`	Counter	Total timed-out share ack transactions

4 Proposed Changes

4.1 Reuse of Existing 2PC Protocol

This KIP reuses Kafka's existing two-phase commit protocol. No new coordinator type or consensus protocol is introduced.

Transaction lifecycle (identical to existing):

EMPTY → ONGOING → PREPARE_COMMIT → COMPLETE_COMMIT
                → PREPARE_ABORT  → COMPLETE_ABORT

What changes is which partitions are added to the transaction:

API Call	Partition Added to Transaction	Storage Topic
`producer.send(record)`	Data topic partition	User topic
`sendOffsetsToTransaction()`	`__consumer_offsets` partition for group	`__consumer_offsets`
`sendShareAcksToTransaction()` (NEW)	`__share_group_state` partition for group+topic	`__share_group_state`

The WriteTxnMarkers request dispatches commit/abort markers to all partitions in the transaction set. If only sendShareAcksToTransaction() was called, markers go only to __share_group_state. If both sendOffsetsToTransaction() and sendShareAcksToTransaction() were called in the same transaction, markers go to both. The transaction coordinator does not distinguish between these — it just tracks partition sets.

4.2 Wire Protocol Changes

New request: AddShareAcksToTxnRequest (mirrors AddOffsetsToTxnRequest)

{
  "apiKey": TBD,
  "type": "request",
  "name": "AddShareAcksToTxnRequest",
  "validVersions": "0",
  "fields": [
    { "name": "TransactionalId", "type": "string", "versions": "0+" },
    { "name": "ProducerId", "type": "int64", "versions": "0+" },
    { "name": "ProducerEpoch", "type": "int16", "versions": "0+" },
    { "name": "GroupId", "type": "string", "versions": "0+" },
    { "name": "Topics", "type": "[]AddShareAcksToTxnTopic", "versions": "0+",
      "fields": [
        { "name": "Name", "type": "string", "versions": "0+" },
        { "name": "Partitions", "type": "[]int32", "versions": "0+" }
      ]
    }
  ]
}

Purpose: Tells the TransactionCoordinator to add the __share_group_state partition(s) for the given {groupId, topicPartition} pair(s) to the producer's ongoing transaction. The partition is determined by ShareCoordinator.partitionFor(groupId, topicPartition), where topicPartition refers to the original data topic partition being acknowledged, and the function maps it to the corresponding __share_group_state internal partition that stores the state for that share-group + data-partition combination.

New request: TxnShareAcknowledgeRequest (mirrors TxnOffsetCommitRequest)

{
  "apiKey": TBD,
  "type": "request",
  "name": "TxnShareAcknowledgeRequest",
  "validVersions": "0",
  "fields": [
    { "name": "GroupId", "type": "string", "versions": "0+" },
    { "name": "TransactionalId", "type": "string", "versions": "0+" },
    { "name": "ProducerId", "type": "int64", "versions": "0+" },
    { "name": "ProducerEpoch", "type": "int16", "versions": "0+" },
    { "name": "Topics", "type": "[]TxnShareAcknowledgeTopic", "versions": "0+",
      "fields": [
        { "name": "TopicId", "type": "uuid", "versions": "0+" },
        { "name": "Partitions", "type": "[]TxnShareAcknowledgePartition", "versions": "0+",
          "fields": [
            { "name": "Partition", "type": "int32", "versions": "0+" },
            { "name": "AcknowledgementBatches", "type": "[]AcknowledgementBatch", "versions": "0+",
              "fields": [
                { "name": "FirstOffset", "type": "int64", "versions": "0+" },
                { "name": "LastOffset", "type": "int64", "versions": "0+" },
                { "name": "AcknowledgeType", "type": "int8", "versions": "0+" }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Purpose: Sent to the ShareCoordinator to write acknowledgments as pending (uncommitted) within the transaction. The acks become visible only when the transaction commits.

4.3 ShareCoordinator Changes

The ShareCoordinator must handle transaction completion, mirroring GroupCoordinator.completeTransaction():

// In ShareCoordinatorShard (NEW method):
public CoordinatorResult<Void, CoordinatorRecord> completeTransaction(
    long producerId,
    short producerEpoch,
    TransactionResult result    // COMMIT or ABORT
) {
    if (result == TransactionResult.COMMIT) {
        // Materialize pending transactional acks into share-group state
        return applyPendingAcknowledgements(producerId, producerEpoch);
    } else {
        // Discard pending transactional acks
        return discardPendingAcknowledgements(producerId, producerEpoch);
    }
}

The existing hook ShareCoordinatorShard.replayEndTransactionMarker() already exists for replaying transaction markers during log recovery. This KIP extends it to also handle live transaction completion.

4.4 State Storage

Transactional acks are written to __share_group_state using CoordinatorRuntime.scheduleTransactionalWriteOperation(). This follows the same pattern used by GroupCoordinator for transactional offset commits to __consumer_offsets.

Records in __share_group_state are written with the producer's producerId and producerEpoch, making them part of the transaction. They become readable by other consumers only after the transaction commits and the WriteTxnMarkers COMMIT marker is written.

5 Flow diagram

CLIENT --> BROKER communication (over the Kafka wire protocol):

  Share Consumer -----> Share Group Coordinator
    ShareFetch, ShareAcknowledge, ShareGroupHeartbeat

  TransactionManager --> Transaction Coordinator
    InitProducerId, AddPartitionsToTxn, AddShareAcksToTxn(NEW), EndTxn

  TransactionManager --> Share Group Coordinator
    TxnShareAcknowledgeRequest (NEW)

  Producer ------------> Data Partition Leaders
    ProduceRequest


BROKER --> BROKER communication (internal, not client-visible):

  Transaction Coordinator --> Data Partition Leaders
    WriteTxnMarkers (COMMIT/ABORT control record)

  Transaction Coordinator --> Group Coordinator (via __consumer_offsets leader)
    WriteTxnMarkers (materializes transactional offset commits)

  Transaction Coordinator --> Share Group Coordinator (via __share_group_state leader) [NEW]
    WriteTxnMarkers (materializes transactional share acks)

Abort case:

Apache Kafka > KIP-1289 Support Transactional Acknowledgments for Share Groups > Screenshot 2026-02-27 at 4.28.46 PM.png

6. Corner Cases

Case 1: Crash BEFORE `beginTransaction()`

poll() -> records [0..9] ACQUIRED
<CRASH>

What happens:

No transaction was started, no output produced, no acks sent
ACQUIRED locks on records 0-9 expire (controlled by share.record.lock.duration.ms)
Broker re-delivers records 0-9 to another member of the share group
No data loss, no duplicates

Case 2: Crash AFTER `send()` but BEFORE `commitTransaction()`

poll() -> records [0..9] ACQUIRED
beginTransaction()
send(output for 0-9)       ← records written to broker, but transactional
<CRASH>

What happens:

Output records are in the partition log but invisible (read_committed consumers skip uncommitted)
No EndTxnRequest was sent
TC detects transaction timeout (transaction.timeout.ms), auto-aborts
TC sends WriteTxnMarkers(ABORT) -> output records get ABORT marker, permanently invisible
Share group: no acks were sent, ACQUIRED locks expire, records 0-9 re-delivered
No data loss, no duplicates

Case 3: Crash AFTER `sendShareAcksToTransaction()` but BEFORE `commitTransaction()`

poll() -> records [0..9] ACQUIRED
beginTransaction()
send(output)
sendShareAcksToTransaction()  ← acks written to SGC as PENDING
<CRASH>

What happens:

Output records: in log, invisible (uncommitted)
Share acks: stored in SGC as PENDING (not materialized)
TC detects timeout, sends WriteTxnMarkers(ABORT) to both data partitions AND __share_group_state
Output: ABORT marker written, records permanently invisible
Share acks: SGC discards pending acks, locks expire, records 0-9 re-delivered
No data loss, no duplicates -- this is the critical case that KIP-1289 solves

Case 4: Crash AFTER `EndTxn(COMMIT)` sent but BEFORE `WriteTxnMarkers` completes

poll() -> records [0..9] ACQUIRED
beginTransaction()
send(output)
sendShareAcksToTransaction()
commitTransaction()            ← EndTxn sent, PREPARE_COMMIT logged
<TC crashes or broker restart>

What happens:

PREPARE_COMMIT is durable in __transaction_state log
When TC recovers (or new leader elected for __transaction_state partition), it replays the log
TC sees PREPARE_COMMIT, resumes sending WriteTxnMarkers(COMMIT) to all partitions
Output records become visible, share acks materialized
No data loss, no duplicates -- the two-phase commit guarantees completion

Case 5: `ProducerFencedException` (zombie detection)

Instance A: beginTransaction(), send(), ...
Instance B: initTransactions() with same transactional.id
            ← TC bumps epoch, A is now a zombie
Instance A: commitTransaction()
            ← TC rejects: ProducerFencedException

What happens:

Instance A's transaction is aborted by the TC (epoch fenced)
Any pending output and share acks from A are discarded
Instance B takes over, re-processes the records
No data loss, no duplicates -- fencing prevents split-brain

Case 6: `abortTransaction()` called explicitly

poll() -> records [0..9] ACQUIRED
beginTransaction()
send(output for 0-4)
record 5 fails validation
abortTransaction()             ← explicit abort

What happens:

TC writes PREPARE_ABORT, sends WriteTxnMarkers(ABORT)
Output records 0-4: ABORT marker, permanently invisible
Share acks (if any sent): discarded
ACQUIRED locks expire, all records 0-9 re-delivered
Application gets fresh batch, can retry
No data loss

Case 7: Partial produce failure (network error to one partition)

beginTransaction()
send("enriched-orders-0", rec1)   ← success
send("enriched-orders-1", rec2)   ← network error, KafkaException

What happens:

Application catches KafkaException, calls abortTransaction()
Same as Case 6: everything rolled back, records re-delivered
No data loss

The Guarantee Matrix

Scenario	Output Records	Share Acks	Records Re-delivered?	Data Loss?	Duplicates?
Happy path (commit)	Visible	Materialized	No	No	No
Crash before txn	Never written	Never sent	Yes (lock expiry)	No	No
Crash mid-txn	Aborted (invisible)	Discarded	Yes (lock expiry)	No	No
Crash after PREPARE_COMMIT	Committed on recovery	Materialized on recovery	No	No	No
Zombie fenced	Aborted	Discarded	Yes (new instance)	No	No
Explicit abort	Aborted (invisible)	Discarded	Yes (lock expiry)	No	No
TC crash after PREPARE	Completed on failover	Completed on failover	No	No	No

The fundamental property: at no point can output records be visible while share acks are uncommitted, or vice versa. They are in the same transaction and share the same COMMIT/ABORT fate.

7. Compatibility, Deprecation, and Migration Plan

Impact on Existing Users

If older broker doesn’t support TxnShareAcknowledgeRequest, fallback to current explicit/implicit ack with warning.
Clients must fail fast on unsupported brokers
No breaking changes for existing Share Group users
`transactional` mode is opt-in via `share.acknowledgement.mode` config
Existing `implicit` and `explicit` modes continue to work unchanged

Migration Path

1. Phase 1: Add `transactional` acknowledgement mode (backward compatible)
2. Phase 2: Streaming frameworks (Flink, Spark) implement transactional sources
3. Phase 3: Documentation and best practices for exactly-once semantics

Deprecation

- No deprecation of existing modes planned
- `transactional` mode recommended for exactly-once use cases

8. Test Plan

Unit Tests

- Transaction state machine transitions
- Idempotency of all transaction operations
- Timeout handling and auto-abort
- Record state transitions (ACQUIRED → ACKNOWLEDGED on commit, ACQUIRED → AVAILABLE on abort/timeout)

Integration Tests

- End-to-end transaction commit/abort flows
- Multi-consumer transactions within same group
- Coordinator failure and recovery
- Network partition scenarios

System Tests

- Flink checkpoint integration with transactional Share Groups
- Exactly-once delivery verification under failures
- Performance benchmarks comparing transactional vs non-transactional modes
- Stress testing with concurrent transactions

Chaos Tests

- Broker failure during PREPARE state
- Coordinator crash before/after prepare
- Consumer crash during transaction
- Network partitions between coordinator and brokers

Include exactly‑once recovery tests similar to Flink e2e:

- Kill after sendShareAcksToTransaction but before commit.
- Kill after commit but before notifyCheckpointComplete.
- Ensure acks are either replayed or visible, never lost.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

Status

1 Motivation

The Goal: Atomic "Read-Process-Write"

1.1 Background: Share Groups

1.2 Why Existing Consumer-Group Exactly-Once Doesn't Apply

1.3 Existing Pattern: sendOffsetsToTransaction()

2. Use Cases

2.1 Consume-Transform-Produce (CTP)

2.2 Flink / Spark Source (No Producer)

2.3 Flink End-to-End Exactly-Once (Source + Sink)

3 Public Interfaces

3.1 KafkaProducer API Addition

3.2 TransactionalShareAcknowledger (Standalone)

3.3 ShareGroupMetadata

3.4 ShareAcknowledgements

3.5 New Metrics

4 Proposed Changes

4.1 Reuse of Existing 2PC Protocol

4.2 Wire Protocol Changes

4.3 ShareCoordinator Changes

4.4 State Storage

5 Flow diagram

6. Corner Cases

Case 1: Crash BEFORE beginTransaction()

Case 2: Crash AFTER send() but BEFORE commitTransaction()

Case 3: Crash AFTER sendShareAcksToTransaction() but BEFORE commitTransaction()

Case 4: Crash AFTER EndTxn(COMMIT) sent but BEFORE WriteTxnMarkers completes

Case 5: ProducerFencedException (zombie detection)

Case 6: abortTransaction() called explicitly

Case 7: Partial produce failure (network error to one partition)

The Guarantee Matrix

7. Compatibility, Deprecation, and Migration Plan

Impact on Existing Users

Migration Path

Deprecation

8. Test Plan

Unit Tests

Integration Tests

System Tests

Chaos Tests

Rejected Alternatives

1.3 Existing Pattern: `sendOffsetsToTransaction()`

Case 1: Crash BEFORE `beginTransaction()`

Case 2: Crash AFTER `send()` but BEFORE `commitTransaction()`

Case 3: Crash AFTER `sendShareAcksToTransaction()` but BEFORE `commitTransaction()`

Case 4: Crash AFTER `EndTxn(COMMIT)` sent but BEFORE `WriteTxnMarkers` completes

Case 5: `ProducerFencedException` (zombie detection)

Case 6: `abortTransaction()` called explicitly