Expose the trace's global tags and span defaults to serializers (OTLP trace/resource-level split)

[dougqh]

What Does This Do

Adds two values to Metadata, the per-span object serializers receive:

• getGlobalTags(): the trace's global tags (DD_TAGS, or their remote-config override);
• getSpanDefaultTags(): the trace's span defaults (DD_SPAN_TAGS plus tracer-defined tags such as env), without the global tags.

DDSpanContext fills both from the trace's config snapshot (TraceCollector.getTraceConfig()), using the maps #12937 added. Every span in a trace shares its collector's snapshot, so a config change mid-trace can't split one trace across two sets of global tags.

getTags() is unchanged and still includes both. Serializers that don't care about tag levels need no changes.

Motivation

This gets #12813 (OTLP) what it needs to write DD_TAGS once on the Resource instead of on every span, without reaching into TagMap internals or comparing values against the static Config:

• Span attributes: the span's direct tags, plus getSpanDefaultTags() minus the keys the span sets itself;
• Resource: getGlobalTags().

The encoder change itself stays with #12813.

The accessors are named for what the tags are, not where they come from. If trace-level state later moves to its own object (a trace segment), only DDSpanContext changes and serializers don't notice.

Additional Notes

• Stacked on Keep DD_SPAN_TAGS when remote config overrides tracing tags (OTLP trace/resource-level split) #12937 (which is stacked on Add test for remote config tracing tags overriding DD_TAGS (OTLP trace/resource-level split) #12936). Review the top two commits.
• Cost: two more references on each Metadata (one per serialized span, on the serializer thread) and one field read from the trace's snapshot. No change on the application thread.
• Tests:
  • new CoreTracerTest.metadataCarriesTheTraceConfigTagLevels: a span started before a config change still serializes its trace's original maps (same instances);
  • existing Metadata constructor call sites in tests pass TagMap.EMPTY;
  • PayloadDispatcherImplTest builds a real DDSpanContext on a mocked PendingTrace whose default answer returned a null snapshot. It now returns a real one. In production the snapshot is never null: PendingTrace and StreamingTraceCollector fall back to captureTraceConfig().
• Local runs:
  • dd-trace-core: the only failures are two Docker-based tests (no Docker locally) and two known timing tests (DDAgentWriterCombinedTest, PendingTraceBufferTest). Both timing tests pass when run on their own.
  • dd-trace-ot passes, and the traceAgentTest and jmh source sets compile.

Jira ticket: [PROJ-IDENT]

🤖 Generated with Claude Code

[datadog-official]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 59.84% (+0.39%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 709a142 | Docs | Give us feedback!}

[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	13.96 s	13.95 s	[-0.8%; +0.9%] (no difference)
startup:insecure-bank:tracing:Agent	12.86 s	12.92 s	[-1.2%; +0.3%] (no difference)
startup:petclinic:appsec:Agent	16.52 s	16.97 s	[-7.1%; +1.9%] (no difference)
startup:petclinic:iast:Agent	16.91 s	16.99 s	[-1.1%; +0.1%] (no difference)
startup:petclinic:profiling:Agent	16.70 s	16.95 s	[-2.5%; -0.5%] (maybe better)
startup:petclinic:sca:Agent	17.07 s	16.99 s	[-0.3%; +1.3%] (no difference)
startup:petclinic:tracing:Agent	16.12 s	16.18 s	[-1.2%; +0.4%] (no difference)

Commit: 709a142d · 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.