prestodb/presto · error · PrestoException

ELASTICSEARCH_TYPE_MISMATCH

ELASTICSEARCH_TYPE_MISMATCH

Error message

Value out of range for field '%s' of type TINYINT: %s

What it means

TinyintDecoder.decode converts an Elasticsearch document field value into a Presto TINYINT. When the source value is a Number whose long value falls outside the signed 8-bit range (-128..127), the decoder throws ELASTICSEARCH_TYPE_MISMATCH because the value cannot be represented as TINYINT. This guards against silent truncation of out-of-range data.

Source

Thrown at presto-elasticsearch/src/main/java/com/facebook/presto/elasticsearch/decoders/TinyintDecoder.java:48

    private final String path;

    public TinyintDecoder(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 Number) {
            long decoded = ((Number) value).longValue();

            if (decoded < Byte.MIN_VALUE || decoded > Byte.MAX_VALUE) {
                throw new PrestoException(ELASTICSEARCH_TYPE_MISMATCH, format("Value out of range for field '%s' of type TINYINT: %s", path, decoded));
            }

            TINYINT.writeLong(output, decoded);
        }
        else {
            throw new PrestoException(ELASTICSEARCH_TYPE_MISMATCH, format("Expected a numeric value for field '%s' of type TINYINT: %s [%s]", path, value, value.getClass().getSimpleName()));
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Widen the Presto column type to SMALLINT/INTEGER/BIGINT in the table mapping and re-run the query
2. Fix the data in Elasticsearch: query for out-of-range documents and clamp or correct them
3. Use a cast in the query after mapping the field as a wider type, e.g. CAST(field AS TINYINT) with explicit clipping via LEAST/GREATEST

Example fix

// before (table mapping)
"myfield": {"type": "tinyint"}
// after
"myfield": {"type": "smallint"}
-- or in query
SELECT LEAST(GREATEST(myfield, -128), 127) AS myfield_tinyint

// Before querying with TINYINT mapping, verify the ES field range
// GET index/_search
// {"size":0,"aggs":{"mn":{"min":{"field":"myfield"}}},"mx":{"max":{"field":"myfield"}}}
// ensure -128 <= mn <= mx <= 127

boolean isTinyintSafe(Object v) {
  return v instanceof Number
      && ((Number) v).longValue() >= Byte.MIN_VALUE
      && ((Number) v).longValue() <= Byte.MAX_VALUE;
}

try { rows = session.execute("SELECT tinyfield FROM idx").fetchAll(); }
catch (PrestoException e) {
  if ("ELASTICSEARCH_TYPE_MISMATCH".equals(e.getErrorCode().getName())) {
    // remap column to SMALLINT/INTEGER and retry
  } else throw e;
}

When it happens

Trigger: Querying an Elasticsearch field mapped as Presto TINYINT whose document value is a number outside -128..127 (e.g. 300, -5000); the mismatch is hit lazily during row decoding, not at query planning.

Common situations: Elasticsearch index has no strict numeric type enforcement (dynamic mapping stored larger integers); the Presto table column was declared TINYINT based on expected range but documents contain larger values; a reindex or bulk import added out-of-range data after the table was defined.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• ELASTICSEARCH_TYPE_MISMATCH
• ELASTICSEARCH_TYPE_MISMATCH
• ELASTICSEARCH_TYPE_MISMATCH
• ELASTICSEARCH_TYPE_MISMATCH
• ELASTICSEARCH_TYPE_MISMATCH

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