feat!: root_span_id handling in otel thread ctx#1834
feat!: root_span_id handling in otel thread ctx#1834gh-worker-dd-mergequeue-cf854d[bot] merged 8 commits intomainfrom
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. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1834 +/- ##
==========================================
+ Coverage 71.48% 71.55% +0.06%
==========================================
Files 426 426
Lines 67304 67350 +46
==========================================
+ Hits 48113 48193 +80
+ Misses 19191 19157 -34
🚀 New features to boost your workflow:
|
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: a0d136d | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
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
|
scottgerring
left a comment
There was a problem hiding this comment.
ACK Ivo's comment about the local root span ID being passed as a [u8; 8] , but otherwise LGTM
0d88fe6 to
cfba812
Compare
c2bc9c6 to
cc1162e
Compare
cc1162e to
345d0c0
Compare
|
/remove |
|
View all feedbacks in Devflow UI.
|
|
Ready to merge, but waiting for #1843 to land which is currently blocking PHP, to avoid a rebase there. |
This reverts commit 7dd922e. After discussion, the spec actually requires UTF8 bytes, so let's enforce that at the type system level.
7050530 to
a0d136d
Compare
Depend on #1831.
What does this PR do?
Follow-up of #1791. Add special handling of the
root_span_idattribute, which is expected to be always provided by downstream users of libdatadog when publishing a thread context.Motivation
Addresses #1791 (comment).
Additional Notes
Since we want to set it automatically and unconditionally, I've opted for the convention that the corresponding key is always set and is always the first in the string table located in the process context. I believe this is reasonable (since we always want to set this attribute) and achievable as long as we control the process-level context publication. But it might be a tad "magic".
Another possibility is to request the user to provide the key for the
datadog.root_span_idattribute. It is a bit less ergonomic for end-users who need to ensure the key is present, and propagate the index to the code that does the context switching so that it can provide it when calling intolibdatadog.How to test the change?
Tests have been updated to reflect the change.