Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Leulz opened this issue Oct 26, 2022 · 3 comments

Comments

@Leulz
Copy link

Leulz commented Oct 26, 2022

protobuf.js version: 6.11.3

I have filed an issue on grpc/grpc-node#2254, and they have told me that I should file an issue here. I will copy and paste some parts describing the problem:

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.

Stack trace:

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)
@Leulz
Copy link
Author

Leulz commented Oct 28, 2022

It seems like it's actually because protobuf.js does not handle an optimization that exists in Rust's prost's implementation, as described in this issue: tokio-rs/prost#99

@acode-x
Copy link
Contributor

acode-x commented Oct 28, 2022

Hi @Leulz ,
I think protobuf.js v7.0.0 fixes above #1348

@Leulz
Copy link
Author

Leulz commented Oct 28, 2022

Hi @Leulz ,
I think protobuf.js v7.0.0 fixes above #1348

Seems like it, thank you for pointing it out!

@Leulz Leulz closed this as completed Oct 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants