prestodb/presto · error · VerifyError
Unsupported type
Error message
Unsupported type
What it means
readNonNullBlock decodes a direct data stream into blocks based on the column's type, supporting BigintType, IntegerType, and SmallintType. Any other type reaching this reader is unsupported and triggers VerifyError("Unsupported type " + type), indicating the stream reader was constructed for a type it cannot decode — a logic/metadata mismatch rather than data corruption.
Source
Thrown at presto-orc/src/main/java/com/facebook/presto/orc/reader/LongDirectBatchStreamReader.java:188
if (type instanceof TimeType) {
long[] values = new long[nextBatchSize];
dataStream.next(values, nextBatchSize);
for (int i = 0; i < values.length; i++) {
values[i] = convertUnits.apply(values[i]);
}
return new LongArrayBlock(nextBatchSize, Optional.empty(), values);
}
if (type instanceof IntegerType || type instanceof DateType) {
int[] values = new int[nextBatchSize];
dataStream.next(values, nextBatchSize);
return new IntArrayBlock(nextBatchSize, Optional.empty(), values);
}
if (type instanceof SmallintType) {
short[] values = new short[nextBatchSize];
dataStream.next(values, nextBatchSize);
return new ShortArrayBlock(nextBatchSize, Optional.empty(), values);
}
throw new VerifyError("Unsupported type " + type);
}
private Block readNullBlock(boolean[] isNull, int nonNullCount)
throws IOException
{
if (type instanceof BigintType) {
return longReadNullBlock(isNull, nonNullCount);
}
if (type instanceof TimeType) {
return longReadNullBlock(isNull, nonNullCount);
}
if (type instanceof IntegerType || type instanceof DateType) {
return intReadNullBlock(isNull, nonNullCount);
}
if (type instanceof SmallintType) {
return shortReadNullBlock(isNull, nonNullCount);
}
throw new VerifyError("Unsupported type " + type);View on GitHub (pinned to 55bb57d202)
Solutions
- Fix the reader factory so the type is mapped to a matching stream reader (e.g. use LongStreamReader or DateStreamReader for DATE)
- Ensure all nodes run the same Presto version to avoid inconsistent type mapping
- Check for custom connectors/plugins overriding type-to-reader mappings and correct them
- Upgrade Presto if the type support was added in a newer release
Example fix
// before return new LongDirectBatchStreamReader(type, ...); // type = DateType // after return new LongStreamReader.StreamReaderFactory(type, ...); // reader matching the declared type
Defensive patterns
Strategy: type-guard
Validate before calling
// Java: before constructing the reader
if (!(type instanceof BigintType) && !(type instanceof IntegerType) && !(type instanceof SmallintType)) {
throw new PrestoException(NOT_SUPPORTED, "Type not supported by long stream reader: " + type);
} Type guard
// Java narrowing helper
static boolean supportedByLongReader(Type t) {
return t instanceof BigintType || t instanceof IntegerType || t instanceof SmallintType;
} Try / catch
// Cannot meaningfully catch VerifyError; prevent instead:
// if (!supportedByLongReader(type)) { use reader factory for type; } Prevention
- Map every Type to its matching stream reader in the reader factory
- Pin all cluster nodes to the same Presto version
- Review custom connector type mappings for drift
- Add unit tests covering all supported types per reader
When it happens
Trigger: readBlock -> readNonNullBlock with a type other than BIGINT/INTEGER/SMALLINT (e.g. DateType or a custom type) mapped onto LongDirectBatchStreamReader.
Common situations: Plugin/connector code creating the wrong stream reader for a type; engine changes mapping new types to the long reader; version skew between Presto nodes (mixed coordinator/worker builds) causing inconsistent type mappings.
Related errors
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/d0cfe1f7a8a3b5b8.
Report an issue: GitHub.