prestodb/presto · error · IllegalArgumentException
Unsupported encoding
Error message
Unsupported encoding
What it means
LongSelectiveStreamReader.startStripe validates that the stripe's stream encoding kind is one this reader supports (DIRECT, DIRECT_V2, DICTIONARY, etc.). When the stripe reports an unknown/unsupported encoding kind, the reader cannot decode it and throws IllegalArgumentException. This typically means the ORC/DWRF file uses an encoding the current Presto version does not implement.
Source
Thrown at presto-orc/src/main/java/com/facebook/presto/orc/reader/LongSelectiveStreamReader.java:93
}
currentReader = directReader;
if (dictionaryReader != null && context.isResetAllReaders()) {
dictionaryReader = null;
System.setProperty("RESET_LONG_READER", "RESET_LONG_READER");
}
break;
case DICTIONARY:
if (dictionaryReader == null) {
dictionaryReader = new LongDictionarySelectiveStreamReader(context);
}
currentReader = dictionaryReader;
if (directReader != null && context.isResetAllReaders()) {
directReader = null;
System.setProperty("RESET_LONG_READER", "RESET_LONG_READER");
}
break;
default:
throw new IllegalArgumentException("Unsupported encoding " + kind);
}
currentReader.startStripe(timezone, stripe);
}
@Override
public void startRowGroup(InputStreamSources dataStreamSources)
throws IOException
{
currentReader.startRowGroup(dataStreamSources);
}
@Override
public String toString()
{
return toStringHelper(this)
.addValue(context.getStreamDescriptor())
.toString();View on GitHub (pinned to 55bb57d202)
Solutions
- Inspect the file's writer version and column encodings (orc-tools `meta` / ORC footer dump) to confirm which encoding kind is present.
- Upgrade Presto to a version that supports the encoding used by the file.
- Re-write the file with a compatible writer (e.g. `SET hive.exec.orc.encoding.style` or rewrite via Hive/Spark with default encodings).
- If the kind is bogus due to corruption, re-copy/regenerate the file and validate checksums.
Defensive patterns
Strategy: validation
Validate before calling
ColumnEncoding encoding = stripe.getColumnEncodings().get(columnId);
if (!SUPPORTED_LONG_KINDS.contains(encoding.getKind())) {
throw new IllegalArgumentException("Stripe encoding " + encoding.getKind() + " unsupported for long column");
} Type guard
boolean isSupportedLongEncoding(ColumnEncodingKind kind) {
return kind == DIRECT || kind == DIRECT_V2 || kind == DICTIONARY || kind == DICTIONARY_V2;
} Try / catch
try {
reader.startStripe(timezone, stripe);
}
catch (IllegalArgumentException e) {
throw new PrestoException(ORC_BAD_DATA, "Unsupported stripe encoding for long column: " + e.getMessage(), e);
} Prevention
- Dump footers with orc-tools when ingesting files from new writers/clusters.
- Keep reader and writer versions aligned; upgrade readers before ingesting files from newer writers.
- Rewrite external files with standard encodings before loading.
- Monitor for encoding kinds appearing in your data lake and add support proactively.
When it happens
Trigger: Reading a stripe whose ColumnEncoding kind falls into the default branch — e.g. a DWRF-specific or newer encoding written by a newer writer version being read by an older Presto.
Common situations: Cross-version file interchange: files written by newer Facebook DWRF writers or other engines read by an older Presto; corrupted stripe metadata in the ORC footer causing a bogus encoding kind; custom forks adding encodings not present upstream.
Related errors
- Unsupported encoding
- Encrypted data size %s exceeds limit of 2^23
- Stripe encryption keys are missing, but file is encrypted
- Number of stripe encryption keys did not match number of enc
- Invalid ORC metadata %s or DWRF stripe cache size %s
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/71e67510c8d9fb45.
Report an issue: GitHub.