apache/beam · error · RuntimeException

Timestamp logical type precision not supported:${precision}

Error message

Timestamp logical type precision not supported:${precision}

What it means

When converting a Beam FieldType with a Timestamp logical type to an Avro schema, only nanosecond precision (precision == 9) is accepted. Any other precision value throws RuntimeException because the library cannot faithfully express that precision in Avro's logical-type model.

Source

Thrown at sdks/java/extensions/avro/src/main/java/org/apache/beam/sdk/extensions/avro/schemas/utils/AvroUtils.java:1229

                  oneOfType.getOneOfSchema().getFields().stream()
                      .map(x -> getFieldSchema(x.getType(), x.getName(), namespace))
                      .collect(Collectors.toList()));
        } else if ("DATE".equals(identifier) || SqlTypes.DATE.getIdentifier().equals(identifier)) {
          baseType =
              LogicalTypes.date()
                  .addToSchema(org.apache.avro.Schema.create(org.apache.avro.Schema.Type.INT));
        } else if ("TIME".equals(identifier)) {
          baseType =
              LogicalTypes.timeMillis()
                  .addToSchema(org.apache.avro.Schema.create(org.apache.avro.Schema.Type.INT));
        } else if (SqlTypes.TIMESTAMP.getIdentifier().equals(identifier)) {
          baseType =
              LogicalTypes.timestampMicros()
                  .addToSchema(org.apache.avro.Schema.create(org.apache.avro.Schema.Type.LONG));
        } else if (Timestamp.IDENTIFIER.equals(identifier)) {
          int precision = checkNotNull(logicalType.getArgument());
          if (precision != 9) {
            throw new RuntimeException(
                "Timestamp logical type precision not supported:" + precision);
          }
          baseType = org.apache.avro.Schema.create(org.apache.avro.Schema.Type.LONG);
          baseType.addProp("logicalType", TIMESTAMP_NANOS_LOGICAL_TYPE);
        } else {
          throw new RuntimeException(
              "Unhandled logical type " + checkNotNull(fieldType.getLogicalType()).getIdentifier());
        }
        break;

      case ARRAY:
      case ITERABLE:
        baseType =
            org.apache.avro.Schema.createArray(
                getFieldSchema(
                    checkNotNull(fieldType.getCollectionElementType()), fieldName, namespace));
        break;

View on GitHub (pinned to 12126d8942)

Solutions

Use TIMESTAMP_NANOSECONDS (precision 9) for the field so conversion succeeds.
Explicitly set the timestamp precision to 9 when constructing the FieldType logical type.
Convert the value to nanoseconds (scale the instant) before writing, or store as LONG without the logical type.
Catch RuntimeException and emit the field with a supported precision or drop it with a warning.

Example fix

// before
FieldType.of(TypeName.DATETIME).withLogicalType(LogicalTypes.timestamp(6))
// after
FieldType.of(TypeName.DATETIME).withLogicalType(LogicalTypes.timestamp(9))

Defensive patterns

Strategy: validation

Validate before calling

boolean isSupportedTimestamp(FieldType ft) {
  LogicalType lt = ft.getLogicalType();
  return lt == null
      || !Timestamp.IDENTIFIER.equals(lt.getIdentifier())
      || (Integer) 9 == checkNotNull(lt.getArgument());
}

Try / catch

try {
  org.apache.avro.Schema s = AvroUtils.toAvroSchema(beamSchema);
} catch (RuntimeException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Timestamp logical type precision not supported:")) {
    // re-map the field to precision 9 and retry
  } else { throw e; }
}

Prevention

Standardize on nanosecond (precision 9) timestamps across pipeline schemas.
Check logical-type precision at schema registration time, not at sink write time.
Scale timestamps to the required precision before writing to Avro.
Pin Beam versions across pipeline stages so default precisions agree.

When it happens

Trigger: Calling AvroUtils.getFieldSchema/toAvroSchema on a FieldType whose logical type identifier is Timestamp and whose precision argument is not 9 (e.g. microsecond precision 6 or millisecond precision 3).

Common situations: Pipeline schemas built with TIMESTAMP logical types read from sources with different precision (e.g. JDBC microseconds), or SDK-version changes where the default timestamp precision differs; writing Beam rows to Avro/Parquet files.

Related errors

AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/8fd43885c8f45ec8. Report an issue: GitHub.