I came across this bug while writing a Kafka consumer in NodeJS, using Redpanda's schema registry. When deserializing the key and value of the message using a schema registry client lib, scalar fields were deserialized just fine but message types were running into all sorts of error while reading tags and decoding their associated data. I was running into similar problems using both kafkajs + @kafkajs/confluent-schema-registry as well as @confluentinc/kafka-javascript and @confluentinc/schemaregistry. Chose to stick with the latter setup and started debugging. I'm here because @confluentinc/schemaregistry depends on @bufbuild/protobuf for its core protobuf logic.

I found that when @confluentinc/schemaregistry fetches the format=serialized form of a proto file from the registry server, and calls createFileRegistry(), the field descriptors for message fields incorrectly ended up with fieldKind: 'scalar'. This led to fields being misinterpreted when the actual Kafka message keys/values were later decoded, here. I traced this back to the serialized proto file from the schema registry omitting type, in favor of type_name, as is permitted according to https://github.com/protocolbuffers/protobuf/blob/c223b2e1fa96feac05f275853e64a87993d557a2/src/google/protobuf/descriptor.proto#L295-L296,

  // If type_name is set, this need not be set.  If both this and type_name
  // are set, this must be one of TYPE_ENUM, TYPE_MESSAGE or TYPE_GROUP.
  optional Type type = 5;