-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[pkg/stanza] key_value_parser: Allow values that contain the delimiter string #29629
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for this fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jmalloc. This makes sense to me.
"quoted-value-contains-delimiter", | ||
func(kv *Config) {}, | ||
&entry.Entry{ | ||
Body: `msg="Message successfully sent at 2023-12-04 06:47:31.204222276 +0000 UTC m=+5115.932279346"`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we also have a test which involves 3+ key value pairs? This would validate we have the correct interaction with pair_delimiter
, and help ensure we do not in the future limit the number of pairs to 2.
Per @djaglowski's request I've added a |
Thanks, all! |
Description:
This PR fixes an issue in the
key_value_parser
operator wherein values containing the delimiter (=
, by default), would cause a parse failure.Given the log body:
The
key_value_parser
would fail with the following error:After this PR, the
key_value_parser
instead emits the following key/value pair:As a result of this change, it is now also possible to parse unquoted values that contain the delimiter. For example
foo=bar=spam
is parsed as("foo", "bar=spam")
. Because there was an existing test case for this failure mode I had considered explicitly disallowing this behaviour for unquoted values. However, I couldn't think of a reason to prefer an error so I decided to float the PR as-is first. FWIW, this behaviour has some prior art, for example parsing of environment variables.Link to tracking Issue:
Testing:
I've added an additional test case named
quoted-value-contains-delimiter
that tests the problematic message I encountered in the wild.I've also replaced the existing
invalid-pair
test as a result of the changed behaviour mentioned above.Documentation: