proto: panic: duplicate enum registered: google.protobuf.FieldDescriptorProto_Type #178
Comments
|
Importing the same package multiple times shouldn't cause multiple runs of its init functions. Is it possible you have the same package being imported under more than one import path? That would cause the observed behaviour. |
|
There is nowhere that I can find it being imported under more than one import path right now, but given that a solution more or less already exists in two other existing PRs it would be much preferable to wait for that. Then we don't have to do our custom imports and this would also be on par with how the python library do it and simplify things quite a bit for cross-langauge support. |
|
Did this ever get any kind of resolution? I'm hitting this issue when trying to use the gcp datastore library and protobufs in the same project. |
|
I, too, am seeing this issue when trying to use any of the google cloud client libraries and protobufs in the same project. |
|
/cc @jba I would echo dsymond's question: are you sure you haven't put the same generated proto under multiple import paths? |
|
@okdave is working on the go-package option in some files. We did recently (a month ago?) put a lot of protos in a common place. For example, FieldMask is now in https://github.com/google/go-genproto/blob/master/protobuf/field_mask.pb.go, which has the import path "google.golang.org/genproto/protobuf". Does this also live under another import path? |
|
If you're seeing this, it would be good to understand your project's layout. It's possible that you'll see this issue with vendoring – for example, having the same proto |
|
I have the same problem, and I'll try to describe what is happening to me. I've tried many different things/layouts, and had 3 problems - and 0 solutions so far. The enum being registered multiple times was the starting point. Problem 1
Problem 2My code was importing github.com/golang/.../descriptor, but the generated proto from the go_proto_library was importing google/protobuf. So I decided to change my code's imports from github.com/golang/.../descriptor to google/protobuf instead. The problem next was that the package github.com/golang/../plugin has a plugin.CodeGeneratorRequest. That proto contains a ProtoFile field, which are of type github.com/golang/.../descriptor.FileDescriptorProto. And this type is then incompatible with google/protobuf.FileDescriptorProto. Problem 3I then decided to move the google/protobuf package to github.com/golang/.../descriptor. But because I use bazel and that the github.com repository is in an external/ directory I'm not supposed to modify it. So I tried to recreate the directory structure github.com/golang/..../descriptor, and move descriptor.proto and the BUILD file there. But now, I have two different packages both producing a github.com/golang/..../descriptor.a object file. And Bazel complains about it, of course. Solution?I think adding descriptor.proto to this repo would actually solve this. I would then have 2 options:
Any other ideas? This may be a little contrived, and I hope my explanations are clear enough. It's relatively unlikely @Globegitter's problem is the same exact thing, but who knows... Thanks! |
|
So to summarize, yes this was due in my case to having descriptor.pb.go in two packages, linked together, but the problem was created by this repo not having both descriptor.pb.go and descriptor.proto. https://github.com/google/go-genproto may be a solution, but then again, for this to work this repo should not have a descriptor.pb.go either, or the output of two libraries will clash (problem 3). I also found #131 like @Globegitter mentioned. I hope this could be resolved soon :) |
|
I have that same issue. Two other third-party packages are using I think |
|
Any solution here? |
|
We are working on de-duplicating the descriptor proto. |
This provides a more reasonable API for obtaining a FileDescriptorProto and DescriptorProto for a given proto.Message — a process that is currently possible (but undocumented) using the public proto API. The major use case for obtaining a DescriptorProto is to decode custom message options, which are encoded as extensions on the MessageOptions submessage. (See https://developers.google.com/protocol-buffers/docs/proto#customoptions.) Fixes #179. PiperOrigin-RevId: 139356528
|
@pongad is actively working on it. |
dsnet
changed the title
|
Closing this as fixed per @pongad's comment. There are multiple ways that a registration conflict can occur:
If you're still experiencing problems, feel free to open a new issue. |
When some of the same messages are redefined anywhere in a Go project, the protobuf package panics (see golang/protobuf#178). Since this package is internal, there is no way to work around it, as one cannot use it directly, but also cannot define the same messages. There is no downside in making the package accessible.
|
my case: |
When some of the same messages are redefined anywhere in a Go project, the protobuf package panics (see golang/protobuf#178). Since this package is internal, there is no way to work around it, as one cannot use it directly, but also cannot define the same messages. There is no downside in making the package accessible.
When some of the same messages are redefined anywhere in a Go project, the protobuf package panics (see golang/protobuf#178). Since this package is internal, there is no way to work around it, as one cannot use it directly, but also cannot define the same messages. There is no downside in making the package accessible.
When some of the same messages are redefined anywhere in a Go project, the protobuf package panics (see golang/protobuf#178). Since this package is internal, there is no way to work around it, as one cannot use it directly, but also cannot define the same messages. There is no downside in making the package accessible.
When some of the same messages are redefined anywhere in a Go project, the protobuf package panics (see golang/protobuf#178). Since this package is internal, there is no way to work around it, as one cannot use it directly, but also cannot define the same messages. There is no downside in making the package accessible.
I am trying to use custom options in our codebase, as mentioned here: https://developers.google.com/protocol-buffers/docs/proto#customoptions
Our codebase actively supports python, go and java. So protos are built against these three environments. It seems while custom options work fine for java and python there seems to be an issue with go leading to following error message when running code coverage on one of our tests:
The issue being here we are importing the module
third_party/proto/google/protobufmultiple times like so:these are being used to set up the coverage before running the actual tests. If I remove these imports and the coverage instrumentation for them all works fine.
So it seems to me that the init function of the
descriptor.pb.gois being called multiple times, which in turn registers the enum multiple times and then fails. I don't quite understand how importing the module multiple times can have any effect. If I import our own protos multiple times (that also register enums) everything seems fine.Is that an issue with the generated code? And is there any way to fix this? (possibly via #131 ?)
The text was updated successfully, but these errors were encountered: