x-pack/filebeat/input/http_endpoint: fix handling of deeply nested numeric values #40115
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
efd6
added
Filebeat
botelastic
bot
added
needs_team
efd6
force-pushed
the
http_endpoint_json_number
branch
3 times, most recently
from
0f63996
to
c03b7c5
Compare
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
…meric values In order to avoid precision loss during processing of numeric values that cannot be exactly represented in a double-precision floating point value, the json.Number unmarshaller is used. This has the effect that conversion to native types on exit from the CEL program fails since protobuf does not handle json.Number. For non-nested values that are referenced by the CEL runtime, this does not caues an issue since the native-to-value conversion will attempt to convert the string representation of the numeric value. This conversion is not recursively applied. Recursively apply the type conversion to all child values on referencing a value; converting numeric values to the most exact type and falling back to a string representation if no native numeric represetation is possible. Also add an undocumented debug function equivalent to the debug that is available in the CEL input and improve error logging.
efd6
force-pushed
the
http_endpoint_json_number
branch
from
c03b7c5
to
b9f3810
Compare
mergify bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
…meric values (#40115) In order to avoid precision loss during processing of numeric values that cannot be exactly represented in a double-precision floating point value, the json.Number unmarshaller is used. This has the effect that conversion to native types on exit from the CEL program fails since protobuf does not handle json.Number. For non-nested values that are referenced by the CEL runtime, this does not caues an issue since the native-to-value conversion will attempt to convert the string representation of the numeric value. This conversion is not recursively applied. Recursively apply the type conversion to all child values on referencing a value; converting numeric values to the most exact type and falling back to a string representation if no native numeric represetation is possible. Also add an undocumented debug function equivalent to the debug that is available in the CEL input and improve error logging. (cherry picked from commit f0401c6) # Conflicts: # x-pack/filebeat/input/http_endpoint/handler.go
6 tasks
mergify bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
…meric values (#40115) In order to avoid precision loss during processing of numeric values that cannot be exactly represented in a double-precision floating point value, the json.Number unmarshaller is used. This has the effect that conversion to native types on exit from the CEL program fails since protobuf does not handle json.Number. For non-nested values that are referenced by the CEL runtime, this does not caues an issue since the native-to-value conversion will attempt to convert the string representation of the numeric value. This conversion is not recursively applied. Recursively apply the type conversion to all child values on referencing a value; converting numeric values to the most exact type and falling back to a string representation if no native numeric represetation is possible. Also add an undocumented debug function equivalent to the debug that is available in the CEL input and improve error logging. (cherry picked from commit f0401c6)
6 tasks
efd6
added a commit
that referenced
this pull request
Jul 8, 2024
…meric values (#40115) (#40134) In order to avoid precision loss during processing of numeric values that cannot be exactly represented in a double-precision floating point value, the json.Number unmarshaller is used. This has the effect that conversion to native types on exit from the CEL program fails since protobuf does not handle json.Number. For non-nested values that are referenced by the CEL runtime, this does not caues an issue since the native-to-value conversion will attempt to convert the string representation of the numeric value. This conversion is not recursively applied. Recursively apply the type conversion to all child values on referencing a value; converting numeric values to the most exact type and falling back to a string representation if no native numeric represetation is possible. Also add an undocumented debug function equivalent to the debug that is available in the CEL input and improve error logging. (cherry picked from commit f0401c6) Co-authored-by: Dan Kortschak <[email protected]>
efd6
added a commit
that referenced
this pull request
Jul 8, 2024
…ling of deeply nested numeric values (#40133) * x-pack/filebeat/input/http_endpoint: fix handling of deeply nested numeric values (#40115) In order to avoid precision loss during processing of numeric values that cannot be exactly represented in a double-precision floating point value, the json.Number unmarshaller is used. This has the effect that conversion to native types on exit from the CEL program fails since protobuf does not handle json.Number. For non-nested values that are referenced by the CEL runtime, this does not caues an issue since the native-to-value conversion will attempt to convert the string representation of the numeric value. This conversion is not recursively applied. Recursively apply the type conversion to all child values on referencing a value; converting numeric values to the most exact type and falling back to a string representation if no native numeric represetation is possible. Also add an undocumented debug function equivalent to the debug that is available in the CEL input and improve error logging. (cherry picked from commit f0401c6) # Conflicts: # x-pack/filebeat/input/http_endpoint/handler.go * remove irrelevant changelog entries * resolve conflicts --------- Co-authored-by: Dan Kortschak <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed commit message
In order to avoid precision loss during processing of numeric values that cannot be exactly represented in a double-precision floating point value, the json.Number unmarshaller is used. This has the effect that conversion to native types on exit from the CEL program fails since protobuf does not handle json.Number. For non-nested values that are referenced by the CEL runtime, this does not cause an issue since the native-to-value conversion will attempt to convert the string representation of the numeric value. This conversion is not recursively applied.
Recursively apply the type conversion to all child values on referencing a value; converting numeric values to the most exact type and falling back to a string representation if no native numeric representation is possible.
Also add an undocumented debug function equivalent to the debug that is available in the CEL input.
Note that an alternative would be to always convert
json.Numberto string. I'm happy with that approach as well.Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Disruptive User Impact
Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs