Skip to content
Kafka Is Fun
ConsumerConsumers

OffsetOutOfRangeException: Fetch position FetchPosition{offset=412, ...} is out of range for partition orders-0

Checked against Kafka 4.2 · Oct 2026Community draft, not yet reviewed by a Kafka specialist

What it means

The consumer asked for an offset that is outside the range the server maintains for the partition: the protocol's error table says "The requested offset is not within the range of offsets maintained by the server." What happens next depends on auto.offset.reset. With a reset policy the client logs "Fetch position ... is out of range for partition ..., resetting offset" and resets without throwing. With none, it raises OffsetOutOfRangeException. A reset to latest can therefore skip records without any exception.

Quick answer

Compare the group's committed offset with the partition's earliest offset. If the group was down for longer than the topic's retention, the records between are gone. Set auto.offset.reset on purpose, and watch lag so you notice before retention deletes unread data.

Likely causes, most common first

  1. The group was offline for longer than the topic's retention

    How to confirm

    The default retention.ms is 604800000 (seven days). If CURRENT-OFFSET in the group's describe output is lower than the partition's earliest offset, retention has already deleted those records. Retention deletes data one log segment at a time.

    confirm
    kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group payments
kafka-get-offsets.sh --bootstrap-server localhost:9092 --topic orders --time -2

    Fix

    Decide what to do about the gap: reset to earliest to read what remains, or to latest to skip it. The documentation says to make sure the consumer instances are inactive first. Then raise retention, or alert on lag, so it does not happen silently again.

    fix
    kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group payments --topic orders --reset-offsets --to-earliest --execute

  2. The topic was deleted and recreated

    How to confirm

    The group's stored offsets are larger than the end of the new topic's log, so they are outside its range.

    Fix

    Reset the group's offsets for that topic. When you recreate topics in development, reset or delete the consumer groups too.

  3. The log end moved backwards, for example after an unclean leader election

    How to confirm

    The committed offset is larger than the log end offset. Check whether unclean.leader.election.enable is true; it is false by default, and the documentation says enabling it lets a replica outside the ISR become leader as a last resort, which may result in data loss.

    Fix

    Reset the group to a valid offset, and find out why a replica outside the ISR became leader. Keep unclean.leader.election.enable=false for topics that must not lose data.

See it happen

Cause data loss with unclean leader election

Opens the simulator with this exercise already running. About 7 minutes.

Reproduce in the simulator

Sources

Every claim above comes from these Apache pages, as of Kafka 4.2. If a page does not say it, this entry does not.

Was this helpful?

Report an issue (opens GitHub in a new tab)

Back to all errors