Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix null handling in proto3 JSON deserializer #763

Merged
merged 1 commit into from Oct 18, 2022

Conversation

osa1
Copy link
Member

@osa1 osa1 commented Oct 13, 2022

proto3 JSON spec says this about null values:

If a value is missing in the JSON-encoded data or if its value is
null, it will be interpreted as the appropriate default value when
parsed into a protocol buffer

proto3 spec does not talk about presence, but in an internal spec we have this about proto3 JSON null values:

When parsing, a “null” value is accepted for all field types. It will
be treated as if the field has the default value (the field itself
would not be set, but its getter will return the default value for
proto3).

So we shouldn't be initializing the fields with null values. The "interpreted as default value" part in the public spec is already handled by the getters.

With this #760 is no longer an issue as we don't generate empty message for the field value when we have a message-field.

We will still accept proto3 JSON message encodings with missing required fields, but that's by design. We don't check for required fields until GeneratedMessage.check is called.

Closes #760

cl/480829988 tests this internally and reports no breakage.

[proto3 JSON spec][1] says this about `null` values:

> If a value is missing in the JSON-encoded data or if its value is
> null, it will be interpreted as the appropriate default value when
> parsed into a protocol buffer

proto3 spec does not talk about presence, but in an internal spec we
have this about proto3 JSON null values:

> When parsing, a “null” value is accepted for all field types. It will
> be treated as if the field has the default value (the field itself
> would not be set, but its getter will return the default value for
> proto3).

So we shouldn't be initializing the fields with `null` values. The
"interpreted as default value" part in the public spec is already
handled by the getters.

With this google#760 is no longer an issue as we don't generate empty message
for the field value when we have a message-field.

We will still accept proto3 JSON message encodings with missing
`required` fields, but that's by design. We don't check for `required`
fields until `GeneratedMessage.check` is called.

Closes google#760

[1]: https://developers.google.com/protocol-buffers/docs/proto3#json
@osa1 osa1 marked this pull request as ready for review October 14, 2022 07:22
@osa1 osa1 requested a review from sigurdm October 14, 2022 07:22
@osa1 osa1 merged commit 76b1389 into google:master Oct 18, 2022
@osa1 osa1 deleted the proto3_null_handling branch October 18, 2022 06:05
osa1 added a commit that referenced this pull request Oct 18, 2022
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.

proto3 JSON required field confusion
2 participants