Fall back to global trace config when a span's own config is null

[dougqh]

What Does This Do

AgentTracer.traceConfig(AgentSpan) returned null whenever the given span itself reported a null TraceConfig (e.g. an ExtractedSpan, which wraps only a remote/propagated context and has no local trace config). It now falls back to the global trace config in that case, the same fallback the method already used when the span itself was null.

Added AgentTracerTest covering: a null span, a span with its own config, and the regression case (an extracted span whose own traceConfig() is null).

Motivation

Several logging instrumentations call traceConfig(span).isLogsInjectionEnabled() after only null-checking span (not the returned TraceConfig), e.g. LogbackLoggerInstrumentation$CallAppendersAdvice:

if (span != null && traceConfig(span).isLogsInjectionEnabled()) {

When the active span is an ExtractedSpan, traceConfig(span) returned null, causing a NullPointerException. It's swallowed by the tracer's own advice-exception handler so it never breaks the instrumented app, but it shows up as a spurious error-tracking issue, misattributed to whatever code happens to be on the calling thread at the time (in the case that prompted this fix, an rxjava2 observer chain, since Logger.callAppenders was invoked synchronously from deep inside it).

The same unguarded pattern is duplicated across five logging integrations (logback, log4j1, log4j2, jboss-logmanager, tinylog), so fixing it at the shared source (AgentTracer.traceConfig) covers all of them at once instead of patching each call site.

Additional Notes

Investigated via a Datadog Error Tracking issue whose stack trace pointed at datadog.trace.instrumentation.rxjava2.TracingSingleObserver.onSuccess — that attribution was a red herring; root-cause writeup posted as a comment on the issue.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
• Update the CODEOWNERS file on source file addition, migration, or deletion (n/a — no files added/moved)
• Update public documentation with any new configuration flags or behaviors (n/a — no config/behavior change)
• Once approved, use merge queue to merge the PR

Jira ticket: [none]

[dougqh]

span.traceConfig returns null for ExtractedSpan.
Arguably, we'd be better fixing ExtracedSpan, but I'm curious what others think.

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[datadog-datadog-prod-us1]

More details

The fallback keeps a span-specific trace configuration. It uses the global trace configuration only when the span or its configuration is null.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit 83e57f8 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.05 s	13.94 s	[-0.1%; +1.6%] (no difference)
startup:insecure-bank:tracing:Agent	13.02 s	13.02 s	[-1.0%; +0.9%] (no difference)
startup:petclinic:appsec:Agent	17.53 s	17.30 s	[+0.4%; +2.4%] (maybe worse)
startup:petclinic:iast:Agent	17.43 s	17.52 s	[-1.4%; +0.3%] (no difference)
startup:petclinic:profiling:Agent	17.62 s	17.23 s	[+1.1%; +3.4%] (significantly worse)
startup:petclinic:sca:Agent	17.52 s	17.45 s	[-0.5%; +1.3%] (no difference)
startup:petclinic:tracing:Agent	16.56 s	16.25 s	[-2.5%; +6.3%] (no difference)

Commit: 83e57f8d · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.