Open xen0n opened 4 years ago
same problem, any method to solve incompatible with v1.4.0 golang/protobuf ?
@FelixSeptem First check if you're affected (if you don't use (gogoproto.gogoproto_import) = false
or gogo/gateway
or gogo/protobuf/jsonpb
then you're NOT affected). If you're as unfortunate as me, it seems the only short-term solution is to downgrade. Keeping 1.4.0
version of upstream protobuf seemingly needs updates to gogo/protobuf
, which at this point seems unlikely, all maintainers disappeared last year without reason.
tl;dr
The following combination is broken:
(gogoproto.gogoproto_import) = false
in proto filesgoogle.protobuf.Timestamp
and friends) are usedgithub.com/golang/protobuf
version >= v1.4.0WKT fields stop being recognized as such by
gogo/protobuf/jsonpb
in this case, breaking serialization.Analysis
With
option (gogoproto.gogoproto_import) = false
set, WKTs are imported fromgithub.com/golang/protobuf/ptypes
packages.For
golang/protobuf
>= v1.4.0 (more exactly golang/protobuf@b9f5089fb9d4f7e6d1126161d93549e300c70f50), theXXX_WellKnownType
methods on WKT types are gone, butgogo/protobuf/jsonpb
is not aware of the protobuf API v2.https://github.com/gogo/protobuf/blob/5628607bb4c51c3157aacc3a50f0ab707582b805/jsonpb/jsonpb.go#L163-L165
https://github.com/gogo/protobuf/blob/5628607bb4c51c3157aacc3a50f0ab707582b805/jsonpb/jsonpb.go#L206-L207
Notably, one of the affected downstream packages is
gogo/gateway
, which is mandatory for grpc-gateway users depending on(gogoproto.stdtime) = true
fields.The protobuf API v2 compatibility, as implemented in
grpc-gateway
, cannot easily be ported togogo/protobuf
. Becausegolang/protobuf
WKT types don't register to the gogo registry, the crucialproto.MessageName()
call will return nothing. And the types cannot just be registered in app code either, because the gogo WKTs also have accompanyingfunc init()
's doing the same thing, the names will collide if one does so.If we don't allow
gogo/protobuf/jsonpb
to somehow lookup the message type ingolang/protobuf
registry, which would create a dependency on the latter package, the bug seems impossible to fix without bumping the fork (which I imagine is non-trivial work) or downgradinggolang/protobuf
(the easiest solution for now).Any thoughts?