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
- 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).
- Re-create the namespace/parser with the desired ParseSpec field names instead of mutating it.
- Guard generic code with an instanceof or capability check before calling setFieldNames.
- 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
- Treat parse specs as immutable; re-create them to change fields.
- Check supported interfaces before generic setFieldNames calls.
- Note FlatDataParser derives fields from its ParseSpec.
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
- Cannot get map view
- Cannot load data from location
- Cannot retrieve map view from lookup
- Reverse lookup not allowed.
- Aggregator[ ] cannot vectorize
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)