-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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/ottl] Validate that all parts of a Key are used by a Context #30051
Comments
**Description:** The desire to validate both path segments AND keys led to a bug where a totally valid statement like `replace_match(body["metadata"]["uid"], "*", "12345")` fails since only `metadata` is checked during parsing; `uid` is checked during hot-path get/set of the value. Failing such a statement is not the intention of #22744 and it was incorrect to fail such a statement. In fact, I believe validating the key's use in the context will be even more complex once we introduce dynamic indexing. For these reasons, this PR removes Key validation for now. If, in the future, we want to re-add these validations, our Interfaces allow that. **Link to tracking Issue:** #22744 #30051 **Testing:** <Describe what testing was performed and which tests were added.> Unit tests Also we wouldve caught this issue earlier if we had an e2e test that did complex indexing but unfortunately we did in the transform processor. All the more reason to implement #28642.
@evan-bradley I though about this some more and I think there is a clean solution if we go back to keys being represented by a slice instead of a linked list. Unlike the path segments, the keys are used during hot-path execution which means the I think we can solve this problem by having OTTL record whether the context asked for all the keys or not. If a context has a requirement to only allow a specific number of keys, such as |
Which is also pretty annoying because |
**Description:** This PR updates OTTL's validation logic to validate the keys are considered during path parsing. Unlike the path, keys are needed during hot path execution. For that reason, the contexts need all the keys during parsing, not an individual key that might be linked to the next key. This PR updates the Path interface to have a list of keys instead of a link to the first Key. This keeps the keys interaction closer to the original key struct from the grammar, which means when the interfaces release we have less breaking changes. **Link to tracking Issue:** <Issue number if applicable> Closes #30051 **Testing:** <Describe what testing was performed and which tests were added.> Added unit tests to validate that indexing fails on paths that dont use keys and pass on paths that allow keys. --------- Co-authored-by: Evan Bradley <[email protected]>
**Description:** The desire to validate both path segments AND keys led to a bug where a totally valid statement like `replace_match(body["metadata"]["uid"], "*", "12345")` fails since only `metadata` is checked during parsing; `uid` is checked during hot-path get/set of the value. Failing such a statement is not the intention of open-telemetry#22744 and it was incorrect to fail such a statement. In fact, I believe validating the key's use in the context will be even more complex once we introduce dynamic indexing. For these reasons, this PR removes Key validation for now. If, in the future, we want to re-add these validations, our Interfaces allow that. **Link to tracking Issue:** open-telemetry#22744 open-telemetry#30051 **Testing:** <Describe what testing was performed and which tests were added.> Unit tests Also we wouldve caught this issue earlier if we had an e2e test that did complex indexing but unfortunately we did in the transform processor. All the more reason to implement open-telemetry#28642.
**Description:** This PR updates OTTL's validation logic to validate the keys are considered during path parsing. Unlike the path, keys are needed during hot path execution. For that reason, the contexts need all the keys during parsing, not an individual key that might be linked to the next key. This PR updates the Path interface to have a list of keys instead of a link to the first Key. This keeps the keys interaction closer to the original key struct from the grammar, which means when the interfaces release we have less breaking changes. **Link to tracking Issue:** <Issue number if applicable> Closes open-telemetry#30051 **Testing:** <Describe what testing was performed and which tests were added.> Added unit tests to validate that indexing fails on paths that dont use keys and pass on paths that allow keys. --------- Co-authored-by: Evan Bradley <[email protected]>
Component(s)
pkg/ottl
Is your feature request related to a problem? Please describe.
OTTL currently validates that a context "consumes" all segments in a path, but does not validate that all a path's keys are used. This means users can do something like
name["foo"]
in the span context and get back the name of the span, completely ignoring thefoo
key. In this scenario the context is allowing parsing to succeed when it shouldnt. To simplify this process for all the different contexts, we can build something into OTTL, similar to Path validation, but for Keys.Things to consider:
map[string]string
would not declare this sincestringMap["key"]["nestedKey"]
would be invalid. But a context would declare this for an attributes path since the type ismap[string]any
andattributes["key1"]["key2"][...]
is valid. - Originally from [pkg/ottl] Don't check that all keys are used #30047 (comment)The text was updated successfully, but these errors were encountered: