apache/pulsar · error · RuntimeException

Currently + type.name() + is not supported

Error message

Currently + type.name() +  is not supported

What it means

validateFieldSchema ends with an explicit rejection of schema types that cannot be used to validate plain Java objects: AUTO_CONSUME, AUTO_PUBLISH, AUTO, KEY_VALUE, JSON, and NONE. These are client-side special/aggregate types with no single-Java-object mapping, so encountering one in field validation throws RuntimeException 'Currently <TYPE> is not supported'.

Source

Thrown at pulsar-common/src/main/java/org/apache/pulsar/client/impl/schema/SchemaUtils.java:156

        if (!foundMatch) {
            throw new RuntimeException("Invalid Java object for schema type " + type
                    + " : " + val.getClass()
                    + " for field : \"" + name + "\"");
        }

        switch (type) {
            case INT8:
            case INT16:
            case PROTOBUF:
            case AVRO:
            case AUTO_CONSUME:
            case AUTO_PUBLISH:
            case AUTO:
            case KEY_VALUE:
            case JSON:
            case NONE:
                throw new RuntimeException("Currently " + type.name() + " is not supported");
            default:
                break;
        }
    }

    public static Object toAvroObject(Object value) {
        if (value != null) {
            if (value instanceof ByteBuffer) {
                ByteBuffer bb = (ByteBuffer) value;
                byte[] bytes = new byte[bb.remaining()];
                bb.duplicate().get(bytes);
                return bytes;
            } else if (value instanceof ByteBuf) {
                return ByteBufUtil.getBytes((ByteBuf) value);
            } else {
                return value;
            }
        } else {

View on GitHub (pinned to 820761864e)

Solutions

1. Declare a concrete, primitive-compatible SchemaType for the field instead of AUTO*/KEY_VALUE/JSON/NONE.
2. If the field is genuinely KEY_VALUE or JSON, define it as a nested structured schema (its own record) so each subfield validates independently.
3. Ensure schema annotations are properly set — SchemaType.NONE usually means the type was never resolved; fix the annotation/registration.
4. Skip validateFieldSchema for such fields and handle them via dedicated JSON/KeyValue schema serializers.

Example fix

// before
@SchemaType(SchemaType.AUTO_CONSUME) private Object payload;
// after
@SchemaType(SchemaType.STRING) private String payload; // or a nested record type with its own schema

Set<SchemaType> unsupported = Set.of(SchemaType.AUTO_CONSUME, SchemaType.AUTO_PUBLISH, SchemaType.AUTO,
    SchemaType.KEY_VALUE, SchemaType.JSON, SchemaType.NONE);
if (unsupported.contains(type)) {
    throw new IllegalArgumentException("field '" + name + "' uses non-validatable schema type " + type);
}

When it happens

Trigger: Invoking field-level schema validation while the field's declared SchemaType is one of AUTO_CONSUME, AUTO_PUBLISH, AUTO, KEY_VALUE, JSON, or NONE — typically when programmatically deriving Avro schemas from POJO fields annotated/inferred with those types.

Common situations: Annotating a POJO field with @AvroSchemaType-like inference that resolves to AUTO/KEY_VALUE/JSON; passing SchemaType.NONE due to an unset/missing schema annotation; auto-schema pipelines calling validateFieldSchema on generic container fields.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• Invalid schema type: ${valueSchema}
• Invalid Java object for schema type + type + : + val.getCl
• Can not enable for all producers but denies for replicators,
• Error during schema compatibility check with strategy ${stra
• This method is not supported

AI-assisted analysis of apache/pulsar@820761864e (2026-09-06). Data as JSON: /api/errors/19ba2011b2664966. Report an issue: GitHub.