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

Descriptor binaries does not match the binaries generated using protoc #1993

Open
NGuldager opened this issue May 14, 2024 · 0 comments
Open

Comments

@NGuldager
Copy link

NGuldager commented May 14, 2024

protobuf.js version: 7.3.0

I would expect that binaries generated with protobufjs to match the ones generated using protoc

Based on the following .proto file

syntax = "proto3";

package reporting.consumption;

service ConsumptionApi {
  rpc ListConsumption (ListConsumptionRequest) returns (ListConsumptionResponse) {}
}

enum IdentifierType {
    SOME_VALUE = 0;
    SOME_OTHER_VALUE = 1;
}

message Identifier {
    IdentifierType type = 1;
}

message ListConsumptionResponse {
  repeated Consumption consumption = 1;
}

message Consumption {
    float consumption = 1;
}

message ListConsumptionRequest {
    oneof consumption {
        Identifier identifier = 1;
    }
}

I get the following differences in the binaries:

From `protbufjs` From `protoc`
    1: "Identifier"
    2 {
      1: "type"
      3: 1
      4: 1
      5: 14
      6: "IdentifierType"
    }
  }
    1: "Identifier"
    2 {
      1: "type"
      3: 1
      4: 1
      5: 14
      6: ".reporting.consumption.IdentifierType"
      10: "type"
    }

We cannot easily get access to the .proto files where we need to generate client code, so having server side reflection from binaries generated by protobufjs is the ideal solution, except that it fails because protoc expects the binaries to look differently compared to what is returned by protobufjs

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

1 participant