You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixed a parser bug where closed enums are parsed incorrectly for non-repeated extensions.
The bug is triggered whenever we parse a value for a closed enum that is not a declared member of the enum. The proper behavior in this case is to put the value to the unknown fields, leaving the extension unset. The first part is being performed correctly -- we are indeed putting the value into the unknown fields. But we currently detect this condition rather late in the decoding pipeline, after the extension has already been created. This causes a stray `0` value to be left in the extension for this field (or, in the unlikely case that the message already contained a value for this field, the extension will contain whatever data was already present in the message).
The observable effects of this bug are:
1. If an invalid value is parsed for a closed enum extension, `HasExtension(foo)` will return true and `GetExtension(foo)` will return a 0, instead of the correct behavior, which is that `HasExtension(foo)` should return false.
2. If the message is later serialized, the extension will be serialized twice, once from the extension list (which will serialize a 0 value) and once from the unknown fields (which will serialize the correct value). This should not be observable in most cases, since the bug only occurs for non-repeated fields, and parsers will overwrite the existing value if a non-repeated field is encountered multiple times on the wire.
PiperOrigin-RevId: 799202921
0 commit comments