-
Notifications
You must be signed in to change notification settings - Fork 1.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
[confmap] Use values as string if YAML is invalid #10794
[confmap] Use values as string if YAML is invalid #10794
Conversation
ce31624
to
cf4efcf
Compare
cf4efcf
to
27c66f5
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10794 +/- ##
==========================================
- Coverage 91.70% 91.70% -0.01%
==========================================
Files 406 406
Lines 18952 18955 +3
==========================================
+ Hits 17380 17382 +2
- Misses 1212 1213 +1
Partials 360 360 ☔ View full report in Codecov by Sentry. |
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.
Can we add a test to replicate the issue in #10787
NVM, I see the second PR |
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Allows any type to be used as a string if the target field is a string or the value is expanded in inline position. Inspired by #10794. This is not a breaking change (previously we would return an error for these). Some things that you can do after this PR that you couldn't do before it: 1. Set `HOST` to `[2001:db8::8a2e:370:7334]` and use it in an endpoint: ```yaml exporters: otlp: endpoint: http://${env:HOST}/api/v1/traces ``` 2. Pass really big numbers as strings (e.g. `10000000000000000000`) 3. Pass `null` as a string. <details> <summary>Types that can be returned by our current YAML parser</summary> Our current way of using the YAML parser has these types: `string`, `nil`, `int`, `uint64`, `float64`, `map[any]any`, `map[string]any`, `[]any`. There is no documentation for this, but the following fuzzing test did not find any failing cases after 20 minutes of continous run: ```go package main import ( "testing" "gopkg.in/yaml.v3" ) func FuzzTest(f *testing.F) { f.Fuzz(func(t *testing.T, data []byte){ var b any err := yaml.Unmarshal([]byte(data), &b) if err != nil { return } switch b.(type) { case string, nil, int, uint64, float64, map[any]any, map[string]any, []any: return default: t.Errorf("Unexpected type %T", b) } }) } ``` </details>
Description
If YAML parsing fails, assume the user wanted to pass the value as a string.
This has the downside that the error messages are less informative: it will tell you it expected something other than a string instead of the YAML parser error.
A future improvement could be to pass these errors down as extra metadata up until the unmarshaling stage.
Link to tracking issue
Fixes #10759
Testing
Added test case for this.