prestodb/presto · error · PrestoException

DECODER_CONVERSION_NOT_SUPPORTED

DECODER_CONVERSION_NOT_SUPPORTED

Error message

could not parse value '%s' as '%s' for column '%s'

What it means

MillisecondsSinceEpochJsonFieldDecoder.getMillis converts a JSON value into epoch milliseconds by calling Long.parseLong on the node's text. When the text is not a valid Java long (e.g. a fractional, empty, or non-numeric string), NumberFormatException is caught and rethrown as a PrestoException with DECODER_CONVERSION_NOT_SUPPORTED. The library throws this because a JSON string/number field cannot be losslessly interpreted as a millisecond timestamp for the requested column.

Source

Thrown at presto-record-decoder/src/main/java/com/facebook/presto/decoder/json/MillisecondsSinceEpochJsonFieldDecoder.java:80

            extends AbstractDateTimeJsonValueProvider
    {
        public MillisecondsSinceEpochJsonValueProvider(JsonNode value, DecoderColumnHandle columnHandle)
        {
            super(value, columnHandle);
        }

        @Override
        protected long getMillis()
        {
            if (value.isIntegralNumber() && !value.isBigInteger()) {
                return value.longValue();
            }
            if (value.isValueNode()) {
                try {
                    return parseLong(value.asText());
                }
                catch (NumberFormatException e) {
                    throw new PrestoException(
                            DECODER_CONVERSION_NOT_SUPPORTED,
                            format("could not parse value '%s' as '%s' for column '%s'", value.asText(), columnHandle.getType(), columnHandle.getName()));
                }
            }
            throw new PrestoException(
                    DECODER_CONVERSION_NOT_SUPPORTED,
                    format("could not parse non-value node as '%s' for column '%s'", columnHandle.getType(), columnHandle.getName()));
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Fix the producing application to emit integer epoch milliseconds for this field.
2. If the source emits seconds, switch the column's dataFormat to 'seconds-since-epoch' instead of 'milliseconds-since-epoch'.
3. If the source emits ISO-8601/RFC2822 strings, use the matching JSON field decoder (e.g. iso8601 / rfc2822 dataFormat).
4. Add a cleanup/coercion step upstream (stream processor) that converts the field to a valid long before Presto reads the topic.
5. Exclude or cast the offending column out of the table definition so the decoder is never invoked on it.

Example fix

// table definition before (fails on ISO strings)
-- ts VARCHAR MAP ... dataFormat = 'milliseconds-since-epoch'
-- after: match decoder to the actual payload format
CREATE TABLE kafka_message (
  ...
  event_time TIMESTAMP WITH TIME ZONE
    WITH (data_format = 'iso8601', mapping = 'ts')
);

// Before querying a 'milliseconds-since-epoch' column, validate the field:
boolean isEpochMillis(String v) {
  if (v == null || v.isEmpty()) return false;
  try { Long.parseLong(v.trim()); return true; } catch (NumberFormatException e) { return false; }
}

// Query wrapper (JDBC)
try (ResultSet rs = stmt.executeQuery(sql)) { ... }
catch (SQLException e) {
  if (e.getMessage() != null && e.getMessage().contains("could not parse value")) {
    log.error("Non-numeric timestamp in decoder column; fix payload or dataFormat", e);
  } else throw e;
}

When it happens

Trigger: Kafka/record decoder table column defined with dataFormat 'milliseconds-since-epoch' whose underlying JSON field's value node text fails Long.parseLong: e.g. '{"ts": "2024-01-01T00:00:00Z"}' or '{"ts": "1704067200.123"}' or '{"ts": ""}' mapped to a bigint timestamp column, when a query reads that column via getMillis.

Common situations: Producers changed the timestamp format (ISO-8601 string instead of epoch millis); timestamps serialized with sub-second precision as decimal; null/empty strings in the payload; users confusing 'milliseconds-since-epoch' with 'seconds-since-epoch' or RFC2822 decoders.

Related errors

• DECODER_CONVERSION_NOT_SUPPORTED
• DECODER_CONVERSION_NOT_SUPPORTED
• TimestampWithTimeZone overflow: %s ms
• nanos must be in range [0, 999_999_999]:
• Type must be a TimestampType for TimeStampSecVector

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