apache/druid · warning · IllegalStateException

Previous sequenceNumbers

Error message

Previous sequenceNumbers %s are no longer available - automatically resetting sequences

What it means

During offset (sequence number) validation the supervisor found partitions whose stored sequence numbers no longer exist in the stream. When resetOffsetAutomatically is enabled it issues a batch reset and throws a StreamException wrapping an ISE to abort the current iteration — the reset will restart readers at valid offsets.

Solutions

No action strictly needed — the supervisor already reset sequences; verify ingestion resumes and data loss from the reset window is acceptable.
If automatic data skipping is undesirable, set resetOffsetAutomatically: false in the tuning config and use the manual reset API instead.
Increase stream retention (Kafka retention.ms / Kinesis retention period) to survive downtime.
If resets happen repeatedly, investigate why offsets keep disappearing (shard expiry, stream recreation).

Example fix

// before: tuningConfig without automatic reset (manual intervention required)
"tuningConfig": { "type": "kafka", "resetOffsetAutomatically": false }
// after: allow automatic reset when offsets vanish
"tuningConfig": { "type": "kafka", "resetOffsetAutomatically": true }

Defensive patterns

Strategy: retry

Validate before calling

// check saved offsets against stream retention before resuming
boolean offsetsValid = partitionsToReset.isEmpty();

Try / catch

try { supervisor.runLoop(); } catch (StreamException e) { if (e.getMessage().contains("automatically resetting sequences")) { awaitNextIteration(); } }

Prevention

Set stream retention well beyond max expected downtime
Enable resetOffsetAutomatically if data loss in gap is acceptable
Monitor reset logs for repeated occurrence

When it happens

Trigger: checkSequenceAvailability detects unavailable offsets for some partitions while taskTuningConfig.isResetOffsetAutomatically() is true; the supervisor then resets those partitions and throws to signal the automatic reset happened.

Common situations: Kinesis shard expiry/merge deleting offsets the supervisor still has saved; stream retention shorter than ingestion downtime so old Kafka offsets were purged; re-created stream with different offsets.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/3e54a8460006270c. Report an issue: GitHub.

Appendix: source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/seekablestream/supervisor/SeekableStreamSupervisor.java:4450

        newTaskGroups.put(
            groupId,
            new TaskGroup(
                groupId,
                simpleStartingOffsets,
                simpleUnfilteredStartingOffsets,
                endOffsets,
                minimumMessageTime,
                maximumMessageTime,
                exclusiveStartSequenceNumberPartitions
            )
        );
      }
    }

    // If any partitions need a reset, issue a single batch reset.
    if (!partitionsToReset.isEmpty()) {
      resetInternal(createDataSourceMetaDataForReset(ioConfig.getStream(), partitionsToReset));
      throw new StreamException(
          new ISE(
              "Previous sequenceNumbers %s are no longer available - automatically resetting sequences",
              partitionsToReset
          )
      );
    }

    for (Entry<Integer, TaskGroup> entry : newTaskGroups.entrySet()) {
      log.info("Initializing taskGroup[%d] with startingOffsets[%s].", entry.getKey(), entry.getValue().startingSequences);
      activelyReadingTaskGroups.put(entry.getKey(), entry.getValue());
    }

    // iterate through all the current task groups and make sure each one has the desired number of replica tasks
    boolean createdTask = false;
    for (Entry<Integer, TaskGroup> entry : activelyReadingTaskGroups.entrySet()) {
      TaskGroup taskGroup = entry.getValue();
      Integer groupId = entry.getKey();

View on GitHub (pinned to 9b90983fd2)