---
title: "Kafka read_committed during a leader election"
description: "An open transaction pins the LSO below the high watermark when the leader dies. The new Kafka leader keeps that LSO, and read_committed waits for the commit."
url: https://monedula.dev/kafka-simulator/scenarios/read-committed-during-election/
---

# Kafka read_committed during a leader election

Scenario 04.2.5 · read_committed during a leader election. Transactions · Advanced · about 3 min · Apache Kafka 4.3.

An open transaction holds the LSO below the HW; killing the partition leader elects a new one, but the LSO survives the election - read_committed stays pinned until commit.

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

## What you start with

A transactional producer holds an open transaction on a single partition - pinning the LSO below the high-watermark - when the partition leader is hard-killed and a new leader is elected from the surviving ISR. The open-transaction state is partition state, so it travels with the leadership handoff.

## Step by step

1. **Cluster ready · two readers** (t+0.000s): orders has 1 partition, RF=3, min.ISR=2, led by broker-1. Group rc is read_committed, ru is read_uncommitted. Nothing written yet. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=04.2.5&t=0)
2. **begin transaction** (t+0.100s): tx1 opens a transaction (transactional.id tx-app-1). No records yet, so the LSO equals the HW. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=04.2.5&t=1)
3. **Produced · uncommitted** (t+1.200s): tx1 wrote two records; both replicate and the HW advances, but the open txn pins the LSO at the txn's first offset. read_uncommitted (ru) reads both; read_committed (rc) is held at the LSO and reads nothing. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=04.2.5&t=2)
4. **Leader killed · electing** (t+2.000s): broker-1 (the partition leader) is hard-killed. The partition is leaderless and electing; the election is still pending. The open txn still holds the LSO down - rc cannot advance. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=04.2.5&t=3)
5. **New leader · LSO still held** (t+2.600s): broker-2 is elected from the surviving ISR (leaderEpoch bumped). The open-txn state is partition state, so it survived the election: the LSO is unchanged and rc is still pinned. The election did not stabilize anything. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=04.2.5&t=4)
6. **commit · LSO releases** (t+3.600s): commit_transaction on the new leader removes the open txn and advances the LSO to the high watermark. read_committed finally drains both records - the election never moved the LSO; only the commit did. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=04.2.5&t=5)

## The takeaway

A leader election does not advance the LSO: read_committed stays pinned across the entire election window and drains the records only once the transaction commits on the new, stable leader.

## Configs in this scenario

- [`min.insync.replicas`](https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_min.insync.replicas): The fewest in-sync replicas, leader included, that must have a write for an acks=all produce to succeed (default 1); with fewer in the ISR the leader rejects the write with NOT_ENOUGH_REPLICAS. [How min.insync.replicas works](https://monedula.dev/kafka-simulator/configs/min-insync-replicas/)
- [`transactional.id`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_transactional.id): A stable name that turns on transactions for a producer (and implies idempotence); a new producer that calls initTransactions() with the same id fences the older one.

## Further reading

- [Apache Kafka documentation](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_isolation.level)