[dev-ankit]

Master Issue: #362

This is the first of two parts. A follow-up PR will expose Client.getSchemaInfo(topic, version) so a consumer can fetch the writer schema for a given version.

Motivation

A consumer of an Avro or JSON topic needs the writer schema version of each message to decode messages produced with an older, compatible schema. The Java client exposes this through Message.getSchemaVersion() and the Python client through Message.schema_version() / int_schema_version(). The bundled C++ client already provides Message::hasSchemaVersion() and Message::getLongSchemaVersion(), but the Node client does not expose them.

Modifications

• src/Message.h, src/Message.cc: add Message.getLongSchemaVersion(). It returns the C++ Message::getLongSchemaVersion() as a number, or null when hasSchemaVersion() is false.
• index.d.ts: declare getLongSchemaVersion(): number | null on Message.
• tstest.ts: add a typing check for the new method.
• tests/end_to_end.test.js: add the getLongSchemaVersion test.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• Added the end-to-end test getLongSchemaVersion. It:
  • subscribes and produces on a fresh topic with JSON schema V1, and asserts the received message reports version 0;
  • produces on the same topic with a compatible schema V2 (V1 plus a field with a default), and asserts the received message reports version 1;
  • produces and consumes on a fresh topic without a schema, and asserts the message reports null. With no schema, the broker registers no schema for the topic and the message metadata carries no schema version, so hasSchemaVersion() is false.

Locally, the test fails if getLongSchemaVersion() returns a constant.

Documentation

• doc-required

• doc-not-needed
  (New Message getter, documented in index.d.ts, which generates the API reference. The client feature matrix has no row for this.)

• doc

• doc-complete

🤖 Generated with Claude Code

[graham-macdonald-simplisafe]

+1 from a Node consumer of Avro-schema'd topics. This unblocks schema evolution for us.

Avro binary is positional, so a consumer can only read a message written with a newer or older (compatible) schema version if it knows the writer's schema and resolves it against its own, e.g. with avsc's readerType.createResolver(writerType). Pulsar stamps every message with the writer's schema version, but the Node client doesn't expose it today, so Node consumers end up decoding with their own schema. That only works while producer and consumer are on the identical schema version; after a compatible change they either throw or mis-read values.

With getSchemaVersion() a consumer can look up the writer schema for that version (registry or cache) and resolve per message, which is what the Go, Java and .NET clients already allow. A number is what we'd use (the registry's /schema/{version} endpoint takes it), and getLongSchemaVersion() avoids the C API's c_str() truncation of the 8-byte version, which is a nice touch.

A Client.getSchemaInfo(topic, version) binding (the follow-up mentioned in #362) would complete the picture by letting consumers fetch the writer schema over the binary protocol rather than the admin REST API.

[gaoran10]

Could we follow the C++ naming convention? Such as Message::GetLongSchemaVersion?

[dev-ankit]

@gaoran10 renamed to Message::GetLongSchemaVersion in the binding