apache/druid · error · IllegalStateException

Unable to fetch the version of the segments in use. The lock

Error message

Unable to fetch the version of the segments in use. The lock for the task might have been revoked

What it means

TombstoneHelper.computeTombstoneSegmentsForReplace throws this when it cannot obtain a version for an existing segment while computing tombstones for a replace (compact/overwrite) operation. Versions come from segment locks held by the task; a null version means the lock no longer exposes a version — usually because the task's lock was revoked (e.g., superseded by a higher-priority task) while the tombstone computation was running.

Source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/common/task/batch/parallel/TombstoneHelper.java:168

        dataSource,
        replaceGranularity,
        maxBuckets
    );

    final List<TaskLock> locks = taskActionClient.submit(new LockListAction());

    Set<DataSegment> tombstones = new HashSet<>();
    for (Interval tombstoneInterval : tombstoneIntervals) {
      String version = null;
      for (final TaskLock lock : locks) {
        if (lock.getInterval().contains(tombstoneInterval)) {
          version = lock.getVersion();
        }
      }

      if (version == null) {
        // Unable to fetch the version number of the segment
        throw new ISE("Unable to fetch the version of the segments in use. The lock for the task might "
                      + "have been revoked");
      }

      DataSegment tombstone = createTombstoneForTimeChunkInterval(
          dataSource,
          version,
          new TombstoneShardSpec(),
          tombstoneInterval
      );
      tombstones.add(tombstone);
    }
    return tombstones;
  }

  /**
   * See the method body for an example and an indepth explanation as to how the replace interval is created
   *
   * @param intervalsToDrop    Empty intervals in the query that need to be dropped. They should be aligned with the

View on GitHub (pinned to 9b90983fd2)

Solutions

Retry the compaction/replace task after ensuring no higher-priority task holds conflicting locks
Increase the compaction task's priority (or lower competing ingestion priority) so its locks are not revoked
Shorten the task's runtime or reduce the interval granularity per run so locks are held for a shorter window
Check overlord logs for lock revocation events around the failure time to identify the preempting task

Example fix

// before: assume lock version is always available
String version = lock == null ? null : lock.getVersion();
// after: re-acquire or validate the lock before computing tombstones
if (version == null) {
  retryLock(dataSource, interval); // re-acquire before proceeding
  version = requireNonNull(lock.getVersion());
}

Defensive patterns

Strategy: retry

Validate before calling

// verify all required locks are still held before computing tombstones
for (TimeChunkLock lock : taskLocks) {
  if (!lockManager.containsLock(dataSource, groupId, lock.getInterval())) {
    throw new IllegalStateException("lock revoked for " + lock.getInterval());
  }
}

Try / catch

catch (ISE e) {
  if (e.getMessage().contains("The lock for the task might have been revoked")) {
    return retryWithBackoff(() -> recomputeTombstones(dataSource, intervals), 3); // re-acquire locks then retry
  } throw e;
}

Prevention

Give compaction/replace tasks sufficient priority so locks aren't preempted
Avoid killing long-running tasks mid-flight; cancel at interval boundaries
Monitor overlord lock-revocation events
Keep replace task intervals small enough to complete within lock lifetime

When it happens

Trigger: During a replace/compaction task, a required time-chunk lock for the target interval was revoked (priority preemption, task kill, or lock expiry) between lock acquisition and version lookup, leaving `version` null.

Common situations: Compaction tasks preempted by higher-priority ingestion tasks; long-running replace tasks whose locks expired; manual task termination while tombstone computation is in flight; misconfigured compaction task priority.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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