feat(ddtrace/tracer): add tracer.StartSpanFromPropagatedContext to start a span from a propagated context#4492
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files
🚀 New features to boost your workflow:
|
BenchmarksBenchmark execution time: 2026-04-14 11:51:12 Comparing candidate commit 6a5ffed in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 215 metrics, 9 unstable metrics.
|
mtoffl01
left a comment
There was a problem hiding this comment.
I think this will be a nice win for our API users 🥳
But, I don't like the name ContinueSpan 😬. I don't think it's accurate -- we're not extending or "continuing" an existing span, we're creating a new one, either as a child of the parent span, or as a root span of a new trace. What about StartSpanFromCarrier? It aligns with the StartSpanFromContext format, and these functions pretty much do the same thing, except one starts a span from a carrier, and the other from a context 😉
kakkoyun
left a comment
There was a problem hiding this comment.
Nice work on this, Dario. The generic TextMapReader constraint is a really elegant choice — it gives us type safety at compile time while keeping things flexible for all carrier types. Much better than having to maintain separate functions per carrier.
I have a few suggestions below, mostly around error semantics and the SpanLinks pattern. Nothing blocking the direction, just things worth discussing.
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 6a5ffed | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
…StartSpanFromPropagatedContext
|
@mtoffl01 it is waiting for you :) |
mtoffl01
left a comment
There was a problem hiding this comment.
This should be a nice improvement to our user experience, thanks for doing it!!!
RomainMuller
left a comment
There was a problem hiding this comment.
That API surface looks fine to me at this stage.
It does not prohibit adding specific helpers (in the future) to cut some boilerplate out if we determine this is useful/necessary (i.e, StartSpanFromHTTPHeadersPropagatedContext or something like that).
What does this PR do?
Adds
tracer.StartSpanFromPropagatedContextto start spans from propagated context.Implements variant D from RFC: https://docs.google.com/document/d/12s7DyHu4AqoC2u_-1aFhod1BcStRAHFlDn1tFuERlMM/edit?tab=t.0. It's A+C because using generics and restricting the carriers to
TextMapReadereffectively implement - at compile time - functions that don't accept carriers ofanytype.It also avoids coupling
ddtrace/tracermore withnet/httpand allows customTextMapReaderimplementers. It's also more flexible if we want to support more carriers.Motivation
Resolves #3598.
Reviewer's Checklist
make lintlocally.make testlocally.Unsure? Have a question? Request a review!