feat(trace-utils)!: add from_string to span text#2011
Conversation
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
| /// Note: Borrow<str> is not required by the derived traits, but allows to access HashMap elements | ||
| /// from a static str and check if the string is empty. | ||
| pub trait SpanText: Debug + Eq + Hash + Borrow<str> + Serialize + Default { | ||
| pub trait SpanText: Debug + Eq + Hash + Borrow<str> + Serialize + Default + From<String> { |
There was a problem hiding this comment.
What does this trait bound add? I can't see that it's necessary.
There was a problem hiding this comment.
It allows to store new strings in the span e.g. an normalized/obfuscated version of a value. Otherwise SpanText instance can only be created from static str.
There was a problem hiding this comment.
If that's the case, then maybe there should be code in the PR that needs it, since everything compiles fine without that trait bound.
There was a problem hiding this comment.
It's needed by @Eldolfin work on the trace filters. It seemed cleaner to do this change separately to be able to discuss it
yannham
left a comment
yannham
left a comment
There was a problem hiding this comment.
Just trying to understand the blast radius: who is using the now cow-based SpanSlice implementation in practice? Is it only for tests, or do others have to pay the cow tax? Maybe it's unavoidable, because any SDK has do deal with the filter/normalization issue anyway?
|
iirc we only use it in the trace_utils decoder when decoding from a slice which is done by python and is going to be used by ruby. All sdks may need to use normalization/obfuscation but not all customers will (for now only those using trace filters). I can add an extra trait |
yannham
left a comment
yannham
left a comment
There was a problem hiding this comment.
I see, thanks. I don't think it's worth the effort anyway, since we're moving towards native spans, and it's not clear that Cow has any measurable impact (it does double the size of &str, but whether that makes any difference...).
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 3f09f0b | Docs | Datadog PR Page | Give us feedback! |
VianneyRuhlmann
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2011 +/- ##
==========================================
+ Coverage 72.67% 72.71% +0.03%
==========================================
Files 452 452
Lines 74889 74946 +57
==========================================
+ Hits 54427 54494 +67
+ Misses 20462 20452 -10
🚀 New features to boost your workflow:
|
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
gh-worker-dd-devflow-36fce6
Bot
added
mergequeue-status: done
and removed
mergequeue-status: in_progress
labels
6 participants
What does this PR do?
Make the span fields mutable by requiring From on SpanText and switching SpanSlice to use Cow
Motivation
Needed to apply normalization on the span, required by trace filters.
Additional Notes
Anything else we should know when reviewing?
How to test the change?
Describe here in detail how the change can be validated.