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

formatter: use the new json lib to relace protobuf json #36530

Merged
merged 2 commits into from
Oct 16, 2024

Conversation

wbpcode
Copy link
Member

@wbpcode wbpcode commented Oct 10, 2024

Commit Message: formatter: use the new json lib to relace protobuf json
Additional Description:

This make our formatter and logger won't depend on the full proto and yaml support. But note the serializer has minor difference with the one that provided by the proto lib.

The NaN and Infinity values of float will be serialized to null and "inf" respectively in the metadata (DYNAMIC_METADATA, CLUSTER_METADATA, etc.) formatter. And the proto one will return an error message.

I personally think in the scenario of formatter and logger, the null and "inf" is better. But this is still a minor behavior change.

Risk Level: low.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
@wbpcode
Copy link
Member Author

wbpcode commented Oct 10, 2024

Hi, cc @jmarantz by the way, why we treat the NaN as null but keep the support to the Infinity?

@wbpcode
Copy link
Member Author

wbpcode commented Oct 10, 2024

/retest

@@ -124,6 +124,10 @@ minor_behavior_changes:
change: |
Sanitize SNI for potential log injection. The invalid character will be replaced by ``_`` with an ``invalid:`` marker. If runtime
flag ``envoy.reloadable_features.sanitize_sni_in_access_log`` is set to ``false``, the sanitize behavior is disabled.
- area: formatter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be runtime guarded?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure. Because, this behavior change means:

For a NaN value, the output of the command will be changed from google.protobuf.Value cannot encode double values for nan, because it would be parsed as a string to null.
For a Infinity value, the output of the command will be changed from google.protobuf.Value cannot encode double values for infinity, because it would be parsed as a string to Inf.

I doubt no one will depend on original behavior. So, not sure if it deserve a runtime flag.

Defer this to you to determine should we need to add a runtime flag for this. Anyway decision is fine to me. :)

#else
IS_ENVOY_BUG("Json support compiled out");
#endif
Json::Utility::appendValueToString(value, str);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do love having one less non-YAML special case, thanks :-)

@jmarantz
Copy link
Contributor

I vaguely remember the decision to render NaN values as 'null' but do not remember thinking one way or the other about 'infinity'. Please do the right thing :)

@wbpcode
Copy link
Member Author

wbpcode commented Oct 11, 2024

I vaguely remember the decision to render NaN values as 'null' but do not remember thinking one way or the other about 'infinity'. Please do the right thing :)

I actually don't know what is right. 😭 So, just kept the JsonStreamer's behavior.

@jmarantz
Copy link
Contributor

There is no concept of 'infinity' in json. If our current serializer can generate 'Infinity' that is invalid Json and we should make it stop :)

https://medium.com/the-magic-pantry/infinity-and-json-cde6df62c17c has some thoughts to substitute 1e1000. 'null' would also be fine.

@alyssawilk
Copy link
Contributor

I have no intuition on the json. I assume NAN shouldn't be used in any case so let's say you can land without runtime guard if you want but wait until after the Tuesday release?
/wait for tuesday :-)

@wbpcode
Copy link
Member Author

wbpcode commented Oct 14, 2024

I have no intuition on the json. I assume NAN shouldn't be used in any case so let's say you can land without runtime guard if you want but wait until after the Tuesday release?
/wait for tuesday :-)

Of course. Thanks for the confirmation.

@wbpcode wbpcode merged commit 6d6e613 into envoyproxy:main Oct 16, 2024
21 checks passed
@wbpcode wbpcode deleted the dev-improve-serialize-of-value branch October 16, 2024 14:14
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.

3 participants