---
title: "OutOfOrderSequenceException in Kafka: causes and fixes"
description: "What OUT_OF_ORDER_SEQUENCE_NUMBER means for a Kafka idempotent or transactional producer, the data loss it usually points to, and when to recreate the producer."
url: https://monedula.dev/kafka-simulator/troubleshooting/out-of-order-sequence/
---

# OutOfOrderSequenceException (OUT_OF_ORDER_SEQUENCE_NUMBER)

Kafka error · OUT_OF_ORDER_SEQUENCE_NUMBER · not retriable.

Exception: `org.apache.kafka.common.errors.OutOfOrderSequenceException`

## Quick answer

The partition leader received a batch whose sequence number does not follow the last one it stored for this producer, so it refused to append it rather than leave a gap. It usually means the broker lost records the producer had already written. Find that loss first; for a transactional producer, closing and recreating it is the safe response.

## What it means

An idempotent producer, the default when no conflicting settings are given, stamps every batch with its producer id, an epoch and a sequence number per partition. The leader remembers the last sequences it accepted and appends a batch only if its sequence is the next one: a duplicate is acknowledged without being written again, and a gap is rejected with OUT_OF_ORDER_SEQUENCE_NUMBER (error code 45). The Javadoc spells out what that implies: data may have been lost. The leader logs the rejection at ERROR, "Error processing append operation on partition ...orders-0", with the exception "org.apache.kafka.common.errors.OutOfOrderSequenceException: Out of order sequence number for producer 1000 at offset 42 in partition orders-0: 7 (incoming seq. number), 4 (current end sequence number)". An idempotent producer without a transactional.id logs "The broker returned org.apache.kafka.common.errors.OutOfOrderSequenceException: ... for topic-partition orders-0 with producerId 1000, epoch 0, and sequence number 7". The producer first retries batches that were out of order only because an earlier one was still in flight. When the gap is real, an idempotent producer without a transactional.id bumps its epoch and restarts that partition at sequence 0, so it keeps sending, but records that were pending may land out of order. For a transactional producer the KafkaProducer Javadoc says the only option left is close(); the 4.3 client treats the error as abortable, but closing is the safe advice. UnknownProducerIdException, the error for a producer id the broker has no state for, is a subclass, so a catch block for OutOfOrderSequenceException catches it too.

## Likely causes, most common first

1. **The leader lost acknowledged records.** After a leader change the new leader may lack batches the old one acknowledged: with acks=1, or acks=all and min.insync.replicas=1, a write can be acknowledged by the leader alone, and an unclean leader election (unclean.leader.election.enable=true) can elect a replica that is missing records. The producer's next sequence then sits beyond the new leader's last one.
2. **A batch expired while later ones were in flight.** With up to five requests in flight per connection, a batch that hits delivery.timeout.ms after it was sent leaves the producer unsure whether the broker stored it. The batches already in flight behind it may then no longer line up with what the broker holds, and the producer waits for them to resolve before it sends more to that partition.

## How to fix it

- Look for the loss first: check whether the partition changed leader around the time of the error, whether unclean leader election is enabled for the topic, and the producer log for "Got error produce response ... Error: OUT_OF_ORDER_SEQUENCE_NUMBER".
- Make acknowledged writes survive a leader change: acks=all, replication factor 3 with min.insync.replicas of at least 2, and unclean.leader.election.enable=false, the default.
- Transactional producer: close() it, create a new one with the same transactional.id (initTransactions() aborts the unfinished transaction) and reprocess from the last committed offsets.
- Idempotent producer: it usually retries past the gap after an epoch bump, so the application often sees no exception; if one surfaces and ordering matters, close and recreate it as the Javadoc advises. Scenario 01.3.3 stops the producer here, the response the Javadoc gives for a transactional producer; a real idempotent producer would carry on.
- Keep max.in.flight.requests.per.connection at 5 or less and retries above 0, as idempotence requires, and give delivery.timeout.ms enough room that batches rarely expire while in flight.

## What not to do

- Turning off enable.idempotence to stop the error: the gap does not go away, it turns into silent duplicates and reordering on retry.

## Does the client retry it?

Not as the same request. The exception is not a RetriableException, but an idempotent producer in Kafka 4.x usually recovers by itself: it bumps its epoch, restarts the partition's sequence at 0 and sends again. For a transactional producer the safe response is to close it and create a new one, as the Javadoc advises, although the 4.3 client itself only marks the transaction as abortable.

## Configs involved

- [`enable.idempotence`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_enable.idempotence): Gives the producer an id and a sequence number per partition so the broker drops duplicate retries and keeps them in order; on by default unless a conflicting setting (acks other than all, retries=0, more than 5 in-flight requests) turns it off.
- [`max.in.flight.requests.per.connection`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_max.in.flight.requests.per.connection): How many unacknowledged requests the producer sends on one connection (default 5); above 1 without idempotence a retried batch can land after a later one, and idempotence needs 5 or fewer.
- [`retries`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_retries): How many times the producer sends a batch again after a transient error (default 2147483647, so in practice delivery.timeout.ms ends the retrying); idempotence needs it above 0.
- [`acks`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_acks): How many replicas must have a write before the producer counts it as sent: 0 (none), 1 (the leader only) or all (every in-sync replica, the default, and required for idempotence).
- [`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.
- [`unclean.leader.election.enable`](https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_unclean.leader.election.enable): Lets a replica that is not in the ISR become leader when no in-sync replica is left, which brings the partition back online but loses the writes that replica never received (default false).
- [`delivery.timeout.ms`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_delivery.timeout.ms): The upper bound on reporting success or failure after send() returns, covering the wait in a batch, the wait for the acknowledgement and every retry (default 120000, 2 minutes); it should be at least request.timeout.ms plus linger.ms.

## Reproduce it in the simulator

- [Kafka idempotent producer dedup vs a plain producer](https://monedula.dev/kafka-simulator/scenarios/idempotence-dedup/) (Idempotent dedup vs duplicate): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=01.3.3&t=5)

## Sources

- [Apache Kafka 4.3 Javadoc: OutOfOrderSequenceException](https://kafka.apache.org/43/javadoc/org/apache/kafka/common/errors/OutOfOrderSequenceException.html)
- [Apache Kafka 4.3 Javadoc: KafkaProducer (send errors with idempotence and transactions)](https://kafka.apache.org/43/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html)
- [Apache Kafka 4.3.0 source: Errors.java (OUT_OF_ORDER_SEQUENCE_NUMBER, code 45)](https://github.com/apache/kafka/blob/4.3.0/clients/src/main/java/org/apache/kafka/common/protocol/Errors.java)
- [Apache Kafka 4.3.0 source: Sender.java (in-flight batches that expire)](https://github.com/apache/kafka/blob/4.3.0/clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java)
- [Apache Kafka 4.3.0 source: TransactionManager.java (epoch bump on a sequence gap)](https://github.com/apache/kafka/blob/4.3.0/clients/src/main/java/org/apache/kafka/clients/producer/internals/TransactionManager.java)
- [Apache Kafka 4.3: producer config enable.idempotence](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_enable.idempotence)
- [Apache Kafka 4.3: producer config max.in.flight.requests.per.connection](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_max.in.flight.requests.per.connection)
- [Apache Kafka 4.3: producer config acks](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_acks)
- [Apache Kafka 4.3: unclean leader election](https://kafka.apache.org/43/design/design/#unclean-leader-election-what-if-they-all-die)
- [Apache Kafka 4.3.0 source: ProducerAppendInfo.java (Out of order sequence number for producer)](https://github.com/apache/kafka/blob/4.3.0/storage/src/main/java/org/apache/kafka/storage/internals/log/ProducerAppendInfo.java)
- [Apache Kafka 4.3.0 source: ReplicaManager.scala (Error processing append operation on partition)](https://github.com/apache/kafka/blob/4.3.0/core/src/main/scala/kafka/server/ReplicaManager.scala)

## Related

- [Kafka messages out of order: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/messages-out-of-order/)
- [Kafka duplicate messages: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/duplicate-messages/)