fix(tracer): use background context instead of panicking on nil ctx in ContextWithSpan#4313
Conversation
BenchmarksBenchmark execution time: 2026-03-30 08:40:28 Comparing candidate commit 59b7717 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 215 metrics, 9 unstable metrics.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
🚀 New features to boost your workflow:
|
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 59b7717 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
5c1d161 to
2a044fc
Compare
…n ContextWithSpan
mtoffl01
left a comment
There was a problem hiding this comment.
f a user has a bug where they accidentally pass nil instead of a context that carried a deadline, cancellation signal, or other values:
Before this change: immediate panic surfaces the bug.
After this change: the code silently proceeds with a bare context.Background(). The span is created and parented, but the context is now detached — no cancellation propagation, no deadline, no user-stored values. This could mask a real bug in the caller's code.
What does this PR do?
When
tracer.ContextWithSpanreceives a nil context, create acontext.Background()instead of panicking. This is consistent with howStartSpanFromContextalready handles nil contexts.Motivation
We spent nearly an hour with @igoragoli debugging a future contrib that was not showing this panic properly.
Rather than panicking, gracefully handling nil context is safer and consistent with the existing pattern in
StartSpanFromContext.Changes
ContextWithSpanwith a fallback tocontext.Background()Reviewer's Checklist
./scripts/lint.shlocally.Unsure? Have a question? Request a review!