apache/druid · error · UnsupportedOperationException

No field names available

Error message

No field names available

What it means

The UriExtractionNamespace FlatDataParser's input row supplier has no notion of configurable field names — the parse spec supplies the field names itself. setFieldNames (and getFieldNames) are therefore unsupported and always throw this UnsupportedOperationException if anything tries to reconfigure the fields on the fly.

Solutions

  1. Do not call setFieldNames on this parser's supplier; the field names come from the configured ParseSpec (e.g. CSV columns or JSON field map).
  2. Re-create the namespace/parser with the desired ParseSpec field names instead of mutating it.
  3. Guard generic code with an instanceof or capability check before calling setFieldNames.
  4. Catch UnsupportedOperationException if callers may legitimately attempt this.

Example fix

// before
rowSupplier.setFieldNames(fieldNames); // UOE
// after
if (!(rowSupplier instanceof Reconfigurable)) { /* field names come from parse spec */ }
Defensive patterns

Strategy: type-guard

Type guard

// java
if (supplier instanceof org.apache.druid.data.input.InputRowSchemaUpdatable) {
  ((InputRowSchemaUpdatable) supplier).setFieldNames(names);
} // else: field names are fixed by the ParseSpec; do not call

Try / catch

// java
try { supplier.setFieldNames(names); }
catch (UnsupportedOperationException e) {
  // rebuild parser with desired ParseSpec instead
}

Prevention

When it happens

Trigger: Calling setFieldNames(...) on the input row supplier obtained from a UriExtractionNamespace FlatDataParser, e.g. generic parser-handling code that reconfigures field names for all parse specs uniformly.

Common situations: Framework code that treats every InputRowSuppler/parse spec generically and calls setFieldNames for normalization; tests or tooling that mutate parser field configuration at runtime.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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

Appendix: source

Thrown at extensions-core/lookups-cached-global/src/main/java/org/apache/druid/query/lookup/namespace/UriExtractionNamespace.java:663

      jsonFactory.configure(JsonFactory.Feature.CANONICALIZE_FIELD_NAMES, false);

      parser = new Parser<>()
      {
        @Override
        public Map<String, String> parseToMap(String input)
        {
          try {
            return jsonFactory.createParser(input).readValueAs(JacksonUtils.TYPE_REFERENCE_MAP_STRING_STRING);
          }
          catch (IOException e) {
            throw new RuntimeException(e);
          }
        }

        @Override
        public void setFieldNames(Iterable<String> fieldNames)
        {
          throw new UOE("No field names available");
        }

        @Override
        public List<String> getFieldNames()
        {
          throw new UOE("No field names available");
        }
      };
    }

    @Override
    public Parser<String, String> getParser()
    {
      return parser;
    }

    @Override
    public boolean equals(Object o)

View on GitHub (pinned to 9b90983fd2)