prestodb/presto · error · PrestoException

ELASTICSEARCH_TYPE_MISMATCH

ELASTICSEARCH_TYPE_MISMATCH

Error message

Expected a string or numeric value for field '%s' of type VARCHAR: %s [%s]

What it means

VarcharDecoder.decode converts Elasticsearch document values into Presto VARCHAR. It accepts String and Number values (via toString), but any other type (Boolean, Map, List, date object, etc.) triggers ELASTICSEARCH_TYPE_MISMATCH because the value cannot be rendered as a string.

Source

Thrown at presto-elasticsearch/src/main/java/com/facebook/presto/elasticsearch/decoders/VarcharDecoder.java:49

    private final String path;

    public VarcharDecoder(String path)
    {
        this.path = requireNonNull(path, "path is null");
    }

    @Override
    public void decode(Hit hit, Supplier<Object> getter, BlockBuilder output)
    {
        Object value = getter.get();
        if (value == null) {
            output.appendNull();
        }
        else if (value instanceof String || value instanceof Number) {
            VARCHAR.writeSlice(output, Slices.utf8Slice(value.toString()));
        }
        else {
            throw new PrestoException(ELASTICSEARCH_TYPE_MISMATCH, format("Expected a string or numeric value for field '%s' of type VARCHAR: %s [%s]", path, value, value.getClass().getSimpleName()));
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Fix or reindex the documents so the field is consistently a string or number
Remap the column and normalize in SQL, e.g. CAST(field AS VARCHAR) if the underlying type is coercible
Add explicit index mappings so Elasticsearch coerces or rejects wrong-typed values at write time

Example fix

// before (mapping allows any type)
"status": true
// after (normalize producer)
"status": String.valueOf(true)

Defensive patterns

Strategy: validation

Validate before calling

// Verify field type homogeneity before mapping as VARCHAR-backed column
// Use a scripted query or _mapping check that all values are string/number

Type guard

boolean isVarcharDecodable(Object v) {
  return v == null || v instanceof String || v instanceof Number;
}

Try / catch

try { pages = elasticsearchPageSource.read(); }
catch (PrestoException e) {
  if ("ELASTICSEARCH_TYPE_MISMATCH".equals(e.getErrorCode().getName())) {
    // reindex offending documents as strings, or widen/adjust the mapping
  } else throw e;
}

Prevention

Use explicit mappings so fields are coerced to string at write time
Reject boolean/object/array writes to string fields via ingest pipelines
Regularly audit dynamic-mapped indices for type drift

When it happens

Trigger: A VARCHAR-mapped Elasticsearch field holds a boolean, array, or object in some documents; decode throws when reading such a document.

Common situations: Dynamic mapping produced mixed types (booleans in a string field); nested objects indexed into a field the Presto mapping declares as VARCHAR; aggregation/scripted fields returning complex values.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/ce2fe428d5a7a815. Report an issue: GitHub.