Open tustvold opened 3 years ago
For what it is worth, I hit this today as well
Here is an example which might help
pbjson produces:
"ReadSource": {
"typeUrl": "type.googleapis.com/com.github.influxdata.idpe.storage.read.ReadSource",
"value": "COLy2v2h1bG1qwEQl/Gxk7nbhPmzAQ=="
},
When the binary value in Any
is decoded, it looks like
org_id: 12351903361995815266
bucket_id: 12966447011416799383
When I manually changed my pbjson to look like this
"ReadSource": {
"@type": "type.googleapis.com/influxdata.platform.storage.read.ReadSource",
"orgId": "12351903361995815266",
"bucketId": "12966447011416799383"
},
...
Then grpcurl was able to handle it
Running into this issue as well with an api that sends the data with the "@type" and unpacked data in the rest of the body. Is there any ideas on how to fix this?
Running into this as well. I'm using pbjson
to do some debugging of Envoy types that use Any
, and having to manually unwrap Any
types is fairly tedious. I'm also generating well-known types as part of prost codegen instead of relying on prost-types, so being able to generate an impl on my own
Any` type would be awesome.
If anyone has time to whip up some tests showing what is wrong / what would help that would be swell. A PR to support it would be even better!
Here's a quick test for serialization. I haven't yet tried an implementation.
https://github.com/influxdata/pbjson/compare/main...blinsay:pbjson:any-tests
In whipping this up I went to go put together a standalone example repo to try and see how deserialization might work and I fell into a gnarly hole trying to configure well-known types. I think one of the hardest things about support here may be configuring other generated code to use this implementation of Any
.
Deserialization seems like it will require some knowledge of existing registered types, and I'm not sure how the whole prost
approaches problems like that.
From https://developers.google.com/protocol-buffers/docs/proto3#json
Currently Any is not special cased and is therefore not serialized/deserialized to/from this custom representation. This should be fixed