protobuf.js icon indicating copy to clipboard operation
protobuf.js copied to clipboard

Error: duplicate name 'constructor' in Type

Open meandthemoon opened this issue 7 years ago • 3 comments

protobuf.js version: 6.8.8

I'm implementing a Node.js client to a service that communicates via protobuf messages. The message contents hold code-related information. For instance, there is a protobuf model similar to the following that represents the context of a function call:

// models.proto
package my.models;

message FunctionCallContext {
    string method_name = 1;
    repeated string arguments = 2;
    bool constructor = 3;
    // etc
}

It appears that the constructor field is causing conflict when I load the models from its .proto file. From a shallow investigation, it looks like the validation is failing simply because the library provides each Message with an identically-named property: https://github.com/dcodeIO/protobuf.js/blob/master/src/type.js#L162

So does this mean the field name is off limits should I choose to use this library? Are there others? Should this be remedied or just documented? Maybe this is an edge case scenario but it seems unfortunate. Also, I don't manage the models, so a "fix" involving an edit to the .proto isn't available to me.

Reproduction: With the model example above, either

require('protobufjs').load(models.proto).then(/* */);

or

pbjs -t json models.proto > bundle.json

will result in

Error: duplicate name 'constructor' in Type FunctionCallContext
    at Type.add (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/type.js:331:15)
    at parseField (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/parse.js:378:16)
    at parseType_block (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/parse.js:338:21)
    at ifBlock (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/parse.js:286:17)
    at parseType (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/parse.js:304:9)
    at parseCommon (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/parse.js:259:17)
    at parse (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/parse.js:728:21)
    at process (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/root.js:107:30)
    at fetch (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/root.js:166:13)
    at Root.load (/Users/matthewhenry/workspace/cs/contrast-node-protect/core/node_modules/protobufjs/src/root.js:194:13)

Commenting out the constructor field of the model will allow the commands to execute without error.

meandthemoon avatar Sep 25 '18 16:09 meandthemoon

Hi,

Does someone have an idea of how to fix it? :)

QuentinBrosse avatar Sep 16 '19 16:09 QuentinBrosse

Is it possible to address this? What would an acceptable fix be? If there are JS specific fields that are off limits (ie constructor) would it be possible for protobuf.js to manage those and alias them?

for example it protobuf.js hits a reserved word/method/property/etc could it mangle the name of the protobuf property, and keep track of the original name for serialization/deserialization?

dm03514 avatar Apr 06 '20 21:04 dm03514

Hi , I am facing same issue Although Issue can be fixed by renaming that variable instead of using reserved word but I prefer if there is some way to bypass this check

Ruithlzz09 avatar Feb 19 '24 07:02 Ruithlzz09