`T` is not assignable to `PartialMessage<T>` for messages with `Oneof` fields
See original GitHub issueFor messages with Oneof
, the generated message type T
is not assignable to PartialMessage<T>
because the generated message type includes a case { case: undefined, value?: undefined }
that is not added by PartialMessage
.
I have a patch for this which seems to fix it for our use-case (both of the additions are necessary): https://github.com/id3as/protobuf-es/commit/c8994e4baa29e694a49ec277ba54896e203b0ad7
Issue Analytics
- State:
- Created 10 months ago
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Question: How to set oneof fields in python? · Issue #5012
"Assignment not allowed to field "a" in protocol message object." is not a oneof problem, it is complain about assignment for message field....
Read more >Argument of type partial is not assignable to parameter of type
I am trying to update partial property of one of interface in TypeScript as below interface details{ name ...
Read more >Protobuf and Go: Handling Oneof Field type - msingh - Medium
This tutorial provides a basic Go introduction to working with protocol buffer Oneof field type. This can come in handy, when dealing with ......
Read more >Protobuf Any and Oneof fields for variant types - Microsoft Learn
Learn how to use the Any type and the Oneof keyword to represent variant object types in messages.
Read more >Decoding protobuf message with a oneof field - MongoDB
I'm using gogo protobuf to generate structs and one of them uses a oneOf, for example: message Foo { oneof bar { Baz...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
OK, cool. Going to close this then. If you notice another problem, feel free to open a new issue.
Agreed. I think we just need to mention that we run our compatibility tests against the default
tsconfig
settings that are generated when runningtsc --init
(with some small exceptions on newer TS versions) and therefore, those settings are what we officially support. I will add this to the docs.