What causes "Unknown loader type[%s]. Known types are %s" in apache/druid?

Load the Druid extension for the segment's storage type (e.g. druid-s3-extensions, druid-hdfs-storage).

apache/druid · error · SegmentLoadingException

Unknown loader type[ ]. Known types are

Error message

Unknown loader type[%s].  Known types are %s

What it means

OmniDataSegmentArchiver.getArchiver throws SegmentLoadingException when the segment's loadSpec 'type' has no registered DataSegmentArchiver. The archiver dispatcher routes to the archiver matching the loadSpec type (e.g. 'local', 's3', 'hdfs'); an unregistered type means the storage type is not supported for archive operations.

Solutions

Load the Druid extension for the segment's storage type (e.g. druid-s3-extensions, druid-hdfs-storage).
Check the loadSpec 'type' in metadata store for typos vs. the configured type list in the error message.
Add the storage extension to druid.extensions.loadList and restart the coordinator.
If the type is genuinely unsupported for archiving, don't archive those segments or write/register a custom DataSegmentArchiver.

Example fix

// before: segment loadSpec type 's3' but extension missing
# druid.extensions.loadList=[]
// after
# druid.extensions.loadList=["druid-s3-extensions"]

Defensive patterns

Strategy: validation

Validate before calling

String type = (String) segment.getLoadSpec().get("type");
if (type == null || !registeredArchiverTypes.contains(type)) {
  throw new IllegalStateException("no archiver for loadSpec type " + type);
}

Type guard

boolean archivable(DataSegment segment) {
  Object t = segment.getLoadSpec().get("type");
  return t instanceof String && knownTypes.contains(t);
}

Try / catch

try {
  archiver.archive(segment, archiveDir);
} catch (SegmentLoadingException e) {
  log.error(e, "no archiver for segment type; load required extension");
}

Prevention

List every deep-storage extension you use in druid.extensions.loadList on coordinators and overlords too.
After storage-type migrations, re-check that all loadSpec types still have support classes.
Avoid hand-editing loadSpec 'type' values.
The error message prints known types — compare against it when configuring.

When it happens

Trigger: archive() or restore() on a DataSegment whose loadSpec type string is absent from the configured archivers map — misspelled type, archiver for that storage not on the classpath/extension loaded, or loadSpec missing 'type'.

Common situations: Running coordinator kill/archive on segments in deep storage whose extension isn't loaded; loadSpec type changed between versions; typo in druid.storage.type; custom storage without a registered archiver.

Understand the failure class

Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.

Related errors

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

Appendix: source

Thrown at server/src/main/java/org/apache/druid/segment/loading/OmniDataSegmentArchiver.java:68

  @Override
  public DataSegment archive(DataSegment segment) throws SegmentLoadingException
  {
    return getArchiver(segment).archive(segment);
  }

  @Override
  public DataSegment restore(DataSegment segment) throws SegmentLoadingException
  {
    return getArchiver(segment).restore(segment);
  }

  private DataSegmentArchiver getArchiver(DataSegment segment) throws SegmentLoadingException
  {
    String type = MapUtils.getString(segment.getLoadSpec(), "type");
    Supplier<DataSegmentArchiver> archiver = archivers.get(type);

    if (archiver == null) {
      throw new SegmentLoadingException("Unknown loader type[%s].  Known types are %s", type, archivers.keySet());
    }

    return archiver.get();
  }

  @VisibleForTesting
  public Map<String, Supplier<DataSegmentArchiver>> getArchivers()
  {
    return archivers;
  }
}

View on GitHub (pinned to 9b90983fd2)