prestodb/presto · error · PrestoException
DECODER_CONVERSION_NOT_SUPPORTED
DECODER_CONVERSION_NOT_SUPPORTED
Error message
cannot decode object of '%s' as '%s' for column '%s'
What it means
Presto's Avro record decoder throws DECODER_CONVERSION_NOT_SUPPORTED when an Avro field value cannot be converted to the declared Presto column type. The getDouble() accessor only accepts Avro values that are Double or Float; anything else (e.g. String, Integer, GenericRecord) is rejected. This signals a mismatch between the Avro schema/actual record data and the Presto table column type mapping.
Source
Thrown at presto-record-decoder/src/main/java/com/facebook/presto/decoder/avro/AvroColumnDecoder.java:168
{
this.value = value;
this.columnType = columnType;
this.columnName = columnName;
}
@Override
public boolean isNull()
{
return value == null;
}
@Override
public double getDouble()
{
if (value instanceof Double || value instanceof Float) {
return ((Number) value).doubleValue();
}
throw new PrestoException(DECODER_CONVERSION_NOT_SUPPORTED, format("cannot decode object of '%s' as '%s' for column '%s'", value.getClass(), columnType, columnName));
}
@Override
public boolean getBoolean()
{
if (value instanceof Boolean) {
return (Boolean) value;
}
throw new PrestoException(DECODER_CONVERSION_NOT_SUPPORTED, format("cannot decode object of '%s' as '%s' for column '%s'", value.getClass(), columnType, columnName));
}
@Override
public long getLong()
{
if (value instanceof Long || value instanceof Integer) {
return ((Number) value).longValue();
}
throw new PrestoException(DECODER_CONVERSION_NOT_SUPPORTED, format("cannot decode object of '%s' as '%s' for column '%s'", value.getClass(), columnType, columnName));View on GitHub (pinned to 55bb57d202)
Solutions
- Change the Presto column type (or the Avro field mapping) to match the actual Avro field type, e.g. use BIGINT/INTEGER for int/long fields
- Ensure the correct writer/reader Avro schema is configured so the field deserializes as float/double
- Add an explicit conversion in the decoder (custom decoder or view with CAST) instead of relying on implicit coercion
Example fix
// before (Presto column: DOUBLE, Avro field: "int") CREATE TABLE t (metric DOUBLE) ...; // after CREATE TABLE t (metric BIGINT) ...; -- matches Avro int/long field
Defensive patterns
Strategy: type-guard
Validate before calling
// Validate Avro schema field types against expected Presto column types before creating/decoding
Schema.Field field = schema.getField(columnName);
if (field.schema().getType() != Schema.Type.DOUBLE && field.schema().getType() != Schema.Type.FLOAT) {
throw new IllegalArgumentException("Column '" + columnName + "' expects a double/float Avro field");
} Type guard
boolean isDecodableAsDouble(Object avroValue) {
return avroValue instanceof Double || avroValue instanceof Float;
} Try / catch
try {
double d = block.getDouble(field);
} catch (PrestoException e) {
if (e.getErrorCode().getName().contains("DECODER_CONVERSION_NOT_SUPPORTED")) {
// fall back to reading as string / log schema mismatch
} else {
throw e;
}
} Prevention
- Keep the Presto table column types in sync with the Avro schema field types
- Validate the Avro schema (e.g. with avro-tools or a schema registry check) before creating the table
- Enable schema-compatibility checks in the registry so field types cannot change incompatibly
- Re-run column mapping generation whenever the Avro schema evolves
When it happens
Trigger: Decoding an Avro record whose field value is not Double/Float while the mapped column requires double (e.g. DOUBLE-typed column whose Avro field is a string or int).
Common situations: Table column declared DOUBLE in Presto but the Avro schema field is int/long/string; schema evolution changed the field type; wrong Avro schema supplied in the Kafka topic decoder config so values deserialize as Strings or GenericFixed.
Related errors
- ELASTICSEARCH_TYPE_MISMATCH
- DECODER_CONVERSION_NOT_SUPPORTED
- BIGQUERY_UNSUPPORTED_TYPE_FOR_VARBINARY
- Invalid array block:
- Invalid map block:
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/cd4f4e66c0bb6263.
Report an issue: GitHub.