-
Notifications
You must be signed in to change notification settings - Fork 2k
feat(component validation): add sink error path validation + multi config #18062
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
Merged
neuronull
merged 43 commits into
master
from
neuronull/component_validation_sink_sad_path
Feb 22, 2024
Merged
Changes from all commits
Commits
Show all changes
43 commits
Select commit
Hold shift + click to select a range
09c562a
add fix and small refactor
neuronull 1e0e6e7
fix compilation errors
neuronull 63a9581
3 ticks
neuronull c6af43e
dont compute expected metrics in validator
neuronull 55a3518
cleanup
neuronull 8ec87b3
cleanup
neuronull 4b3b721
clippy
neuronull f9854bf
feedback tz: sent_eventssssss
neuronull 0577ee6
feedback tz: fix telemetry shutdown finishing logic
neuronull 51e9ab4
3 ticks
neuronull 99a2d20
Merge branch 'master' into neuronull/draft_component_validation_bette…
neuronull e8cdf11
small reorg to add sinks
neuronull c460a49
mini refactor of the component spec validators
neuronull 3daced5
attempt to set expected values from the resource
neuronull b7a7bd3
feedback tz- from not try_from
neuronull af7e9b2
Merge branch 'neuronull/draft_component_validation_better_validation'…
neuronull 0ce0e25
back to 3 ticks
neuronull 35efd5a
fix incorrect expected values
neuronull 1f4ea02
Even more reduction
neuronull e8b17af
clippy
neuronull cdeab8f
add the discarded events total check
neuronull a0f7a65
Merge branch 'master' into neuronull/draft_component_validation_bette…
neuronull 0a6c056
Merge branch 'neuronull/draft_component_validation_better_validation'…
neuronull 77c110b
Merge branch 'master' into neuronull/component_validation_sink_compon…
neuronull 006db51
workaround the new sync issues
neuronull 604abea
multi config support
neuronull 82faf6c
cleanup
neuronull 4745a2f
Merge branch 'master' into neuronull/component_validation_sink_compon…
neuronull b8650d0
Merge branch 'neuronull/component_validation_sink_component_spec' int…
neuronull 1a43e8b
check events
neuronull f54bdac
Merge branch 'master' into neuronull/component_validation_sink_compon…
neuronull 26bde95
Merge branch 'neuronull/component_validation_sink_component_spec' int…
neuronull f6aa019
partial feedback
neuronull a2689fe
thought i removed that
neuronull 3ff66e0
use ref
neuronull 73b8689
Merge branch 'neuronull/component_validation_sink_component_spec' int…
neuronull 5d5e019
Merge branch 'master' into neuronull/component_validation_sink_sad_path
neuronull 7d17599
feedback: dont introduce PassThroughFail variant
neuronull da6267c
feedback: adjust enum variant names for clarity
neuronull b5a2388
feedback: no idea what I was thinking with `input_codec`
neuronull 94fcdbd
spell check
neuronull f560911
fr
neuronull 0415759
feedback- update docs
neuronull File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
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.
What scenarios do we have where we want to inject an additional field but don't want to have the event fail?
If that's common, then we probably want to add a variant to
EventDatathat allows us to deserialize from a map, maybe something like...I think this would be sufficient to allow us to define events like so:
Again, I think this would work, and perhaps more importantly (at least in my mind, but this point is just a loosely-held opinion) it would be somewhat clearer because in order to construct a more advanced event (beyond just the raw message), we wouldn't be limited to just the raw message and a single field to inject. This would end up letting us actually write event data that, for example, where a log event doesn't even have a
messagefield, and so on. A future improvement could then be to make the failure inducing modes be their own enum type -- a variant for "should fail on its own", a variant for "should fail if we mess up the encoding", and so on -- and then that failure type could just be a dedicated field such that the event data definitions might end up looking like:It was always sort of my plan to make
EventDatawork this way, with the single string variant as an escape hatch for defining basic log events without any additional boilerplate while more advanced variants had dedicated variants, especially since we might eventually want to test metrics this way, and we'd need an answer for that.All of that said, I realize we're focusing primarily on log-specific components right now and so this is purely a suggestion on how we might be able to make this a little more generalized out of the gate.
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.
Yeah that is a good point. I think when I made that optional I was thinking about making it flexible so we could hit specific code paths in the components. We don't really have a need for this right now plus as you pointed out it may be more useful for metrics cases.
The changes you suggest, make sense to me.
One thing to note (and I was planning to tell you this today 😅 ) , In my branch to fix the synchronization issues, I actually removed this code path for injecting specific fields. In that branch I ended up changing the error validation for sinks to not rely on the codecs for the errors, and instead generate it from the external resource. I felt this was more of a realistic scenario.
In any case, for all the reasons you mentioned and the ones I added, I'll leave this comment open and we can refer back to it if/when we need to add this functionality.
Thanks!