Fixing client serialization bugs #402

jasonmreding · 2025-01-09T00:06:18Z

Description

This addresses a number of client serialization issues around sparse enums and oneof fields.

In the case of sparse enums, we failed to translate back from the proto enum value to the LV enum value. This would result in the LV enum value always showing the last enum value.
For oneof fields we failed to assign the selected_index field in the cluster which made it look like no fields from the oneof were ever set when reading response data on the client.
This also fixes an issue where we sometimes were serializing the selected_index field across the wire which would end up getting captured in the unknown fields in the message on the other end.
Messages containing more than one oneof field were not getting the selected_index field set correctly on their class cluster.

Implementation

Most of these were only issues with the LVMessageEfficient derived class which I believe is only used for unary calls from the client. Otherwise, we end up using the ClusterDataCopier methods which already handled this.

LVMessage now tracks data for which field of a oneof is selected. This data structure is updated when parsing a message. It is also updated by ClusterDataCopier when constructing a LVMessage from its cluster representation.
LVMessageEfficient now assigns the selected_index field in the class cluster for a oneof during PostInteralParseAction using the new data structure added to LVMessage.
LVMessageEfficient now has a hand written override for ParseEnum which translates from enum values from a proto file (which can be "sparse" or non-sequential) to the LV assigned enum value for the cluster since LV only supports sequential enum values.
When assigning selected_index field values for the class cluster, we now iterate over _elements instead of _mappedElements. Since we use -1 as the field number for all selected_index fields, there will only ever be one entry in _mappedElements. This obviously doesn't work if the message has more than one oneof field.

Testing

Manually tested generation of both the client and the server using proto APIs that included nested messages, enums, and oneof fields. Tested both Win32 and Win64 using LV 2019 and LV 2024.

…ds. Also fixed an issue where we sometimes were serializing the selected_index field across the wire which would end up getting captured in the unknown fields.

src/cluster_copier.cc

src/lv_message_efficient.h

src/lv_message_efficient.cc

* master: Run grpc code generation in a private application context (#401)

src/lv_message.cc

src/cluster_copier.cc

src/lv_message_efficient.h

src/lv_message_efficient.cc

…u-22.04.

Fixing client serialization issues around sparse enums and oneof fiel…

c010f49

…ds. Also fixed an issue where we sometimes were serializing the selected_index field across the wire which would end up getting captured in the unknown fields.