apache/pulsar · error · SchemaSerializationException

Not implemented for ${this.getClass}

Error message

Not implemented for ${this.getClass}

What it means

AbstractSchema.atSchemaVersion(byte[]) adapts a schema to a specific schema version. If the schema does not support schema versioning the current instance is returned; otherwise the default implementation throws this SchemaSerializationException, meaning the schema claims versioning support but has not implemented per-version schema resolution.

Source

Thrown at pulsar-client/src/main/java/org/apache/pulsar/client/impl/schema/AbstractSchema.java:84

    @Override
    public Schema<T> clone() {
        return this;
    }

    /**
     * Return an instance of this schema at the given version.
     * @param schemaVersion the version
     * @return the schema at that specific version
     * @throws SchemaSerializationException in case of unknown schema version
     * @throws NullPointerException in case of null schemaVersion and supportSchemaVersioning is true
     */
    public Schema<?> atSchemaVersion(byte[] schemaVersion) throws SchemaSerializationException {
        if (!supportSchemaVersioning()) {
            return this;
        }
        Objects.requireNonNull(schemaVersion);
        throw new SchemaSerializationException("Not implemented for " + this.getClass());
    }
}

View on GitHub (pinned to 820761864e)

Solutions

  1. Override atSchemaVersion(byte[]) in your schema to resolve the correct Schema<?> for the version.
  2. If your schema truly has no per-version behavior, make supportSchemaVersioning() return false so `this` is returned instead of throwing.
  3. Avoid calling atSchemaVersion on schemas that don't support versioning; check supportSchemaVersioning() first.

Example fix

// before
public boolean supportSchemaVersioning() { return true; } // but no atSchemaVersion override
// after
public boolean supportSchemaVersioning() { return false; }
// or implement:
public Schema<?> atSchemaVersion(byte[] v) {
  SchemaInfo info = schemaInfoProvider.getSchemaByVersion(v).join();
  return Schema.getSchemaInfoBasedSchema(info);
}
Defensive patterns

Strategy: type-guard

Validate before calling

if (schema.supportSchemaVersioning()) { /* ensure the schema also overrides atSchemaVersion before calling it */ }

Type guard

boolean supportsAtSchemaVersion(Schema<?> s) { try { s.getClass().getDeclaredMethod("atSchemaVersion", byte[].class); return true; } catch (NoSuchMethodException e) { return false; } }

Try / catch

try { Schema<?> v = schema.atSchemaVersion(version); } catch (SchemaSerializationException e) { /* fall back to the base schema */ }

Prevention

When it happens

Trigger: Calling atSchemaVersion(schemaVersion) with a non-null version on an AbstractSchema subclass whose supportSchemaVersioning() returns true but which does not override atSchemaVersion — typical with custom schemas that advertise versioning support.

Common situations: Custom schema implementations overriding supportSchemaVersioning() but not atSchemaVersion(); broker-side message re-encoding paths requesting schema-version-aware decoding against a generic/custom schema.

Related errors


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