Skip to content

Conversation

@copybara-service
Copy link

Fix Any hasbit consistency issue in OSS.

Any value field is a bytes field in OSS, and since cl/792909628 (#22956), _internal_mutable_*() accessors for string fields don't set hasbits. This can cause the hasbit to be missing for the value field of Any after calling PackFrom, which will serialize incorrectly.

This change also includes fixes to any_test, which failed to catch this bug. We got unlucky, and every test which checked a roundtrip PackFrom -> UnpackTo for an Any field reused the same Any object, calling MessageLite::ParseFromString (which Clear()s it) on the same object. However, Clear() skips string fields whose hasbits are not set. This meant the string value field of the Any was not cleared, since its hasbit had not been properly set by PackFrom. So even though the Any value skipped serializing its value, the reused Any object still contained the expected string value serialization of the submessage, and UnpackTo worked correctly.

The culprit change was adopted in release 33.0, so it will need to be patched to this version.

See #24258.

Fixes #24258

`Any` `value` field is a `bytes` field in OSS, and since cl/792909628 (#22956), `_internal_mutable_*()` accessors for string fields don't set hasbits. This can cause the hasbit to be missing for the `value` field of `Any` after calling `PackFrom`, which will serialize incorrectly.

This change also includes fixes to `any_test`, which failed to catch this bug. We got unlucky, and every test which checked a roundtrip `PackFrom` -> `UnpackTo` for an `Any` field reused the same `Any` object, calling `MessageLite::ParseFromString` (which `Clear()`s it) on the same object. However, `Clear()` skips string fields whose hasbits are not set. This meant the `string value` field of the `Any` was not cleared, since its hasbit had not been properly set by `PackFrom`. So even though the `Any` value skipped serializing its value, the reused `Any` object still contained the expected `string value` serialization of the submessage, and `UnpackTo` worked correctly.

The culprit change was adopted in release 33.0, so it will need to be patched to this version.

See #24258.

Fixes #24258

PiperOrigin-RevId: 828236584
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Any::PackFrom broken in protobuf 33.0 (regression)

2 participants