Decoding of map<int64, Message> results in error if a Message has only default values

[Leulz]

Problem description

When trying to receive a message with a map whose value is a message with only default values as fields, I get an error like this: Response message parsing error: Cannot read properties of null (reading 'field').

Reproduction steps

I have a proto3 file that defines a service with a method that returns a message like the Outer here:

message Outer {
    map<int64, Inner> inners = 1;
}

message Inner {
    int64 field = 1;
}

If Outer has only one key-value pair, whose Inner has the field with its default value (in this case, 0), I am getting an error like the following: Response message parsing error: Cannot read properties of null (reading 'field'). This happens even when I pass defaults: true. By the way, I am doing this using NestJS, which uses @grpc/proto-loader by default.

I have tried changing the loader configurations, but to no avail. The error persists.

I have confirmed that the error is with not passing any field different from the type's default by adding a second field to the Inner message and sending an Outer like Outer { inners: {1: Inner {field: 0, other_field: 1}}}. Everything worked then.

My understanding is that protobuf 3 makes it so a Message with only default values is not sent over the wire. But even then, should it not be possible for a gRPC client to understand a not-sent-message as its default? Otherwise, how should that case be handled when using grpc-loader?

If this is an already known problem and I am simply doing something wrong, then any guidance is appreciated. If, however, this error is strange to you too, I can try to create a repository later reproducing it.

Environment

• OS name, version and architecture: Mac OS Darwin Kernel Version 21.6.0 ARM64
• Node version: v16.14.0
• Node installation method: nvm
• Package name and version : "@grpc/grpc-js": "^1.6.1", "@grpc/proto-loader": "^0.7.3"

Additional context

I have added a log of the trace inside of the catch of the error inside of the client-interceptor's onReceiveMessage, and this is what I see (with some things redacted or changed to be similar to the example above):

TypeError: Cannot read properties of null (reading 'field')
    at Type.Inner$toObject [as toObject] (eval at Codegen (.../node_modules/@protobufjs/codegen/index.js:50:33), <anonymous>:19:8)
    at Type.toObject (.../node_modules/@grpc/proto-loader/node_modules/protobufjs/src/type.js:567:25)
    at Type.MessageThatContainsTheMap$toObject [as toObject] (eval at Codegen (.../node_modules/@protobufjs/codegen/index.js:50:33), <anonymous>:29:34)
    at Type.OuterMessageThatContainsMessageThatContainsTheMap$toObject [as toObject] (eval at Codegen (.../node_modules/@protobufjs/codegen/index.js:50:33), <anonymous>:13:32)
    at Type.toObject (.../node_modules/@grpc/proto-loader/node_modules/protobufjs/src/type.js:567:25)
    at Object.deserialize [as responseDeserialize] (.../node_modules/@grpc/proto-loader/src/index.ts:209:16)
    at Object.onReceiveMessage (.../node_modules/@grpc/grpc-js/src/client-interceptors.ts:408:48)
    at .../node_modules/@grpc/grpc-js/src/call-stream.ts:402:22
    at processTicksAndRejections (node:internal/process/task_queues:78:11)

Also, I do not know if this is useful information, but the server that sends the message is a server written in Rust, using tonic.

[murgatroid99]

I agree that this looks like a bug, but the proto-loader library is just a thin wrapper around protobuf.js. Any decoding bug will need to be fixed there, so your best option is to file a bug there.