Add test for remote config tracing tags overriding DD_TAGS

[dougqh]

What Does This Do

Adds CoreTracerTest.remoteConfigTracingTagsOverrideGlobalTags. With DD_TAGS=local_key:local_val, it checks that:

• remote config tracing_tags replaces the global tags (local_key is gone, rc_key is present);
• removing the override restores DD_TAGS.

Test-only; no behavior change.

Motivation

Our general rule is that remote config overrides the corresponding local config. For tracing tags, the cross-language test (system-tests TestDynamicConfigV2.test_tracing_client_tracing_tags) says "Ensure local tags are overridden and RC tags applied", but its assertion (assert_trace_has_tags) only checks that the RC tags are present. A library that merged RC tags with DD_TAGS would still pass. The existing Java test, verifyConfigurationPollingWithCustomTags, starts with no local tags, so it can't tell "replace" from "merge" either.

This matters for upcoming core work: splitting DD_TAGS from span defaults in the config snapshot, so the OTLP exporter can put DD_TAGS on the Resource without repeating them on every span (see #12813). That split needs to know which local config RC tracing_tags corresponds to.

Additional Notes

Question: what should RC tracing_tags do to DD_SPAN_TAGS?

Today, the tracer keeps one tracingTags map, initialized from Config.getMergedSpanTags() (DD_TAGS + DD_SPAN_TAGS). The RC override replaces that whole map, so DD_SPAN_TAGS are dropped while an RC tag override is active, and come back when it's removed. I confirmed this with a test (details in a comment below).

If RC tracing_tags corresponds to DD_TAGS only, as the system-test's wording suggests, then dropping DD_SPAN_TAGS is a bug. This PR deliberately doesn't pin either behavior for DD_SPAN_TAGS. If anyone knows the intended behavior (or of a cross-language spec for it), please comment.

Jira ticket: [PROJ-IDENT]

🤖 Generated with Claude Code

[dougqh]

Flag: an RC tracing_tags override drops DD_SPAN_TAGS.

I first wrote this test as a table with a second row: trace.span.tags=local_key:local_val, expecting both the span tags and the RC tags while the override is active. On master, that row fails:

expected: <{local_key=local_val, rc_key=rc_val}> but was: <{rc_key=rc_val}>

Why:

• At startup, CoreTracer sets tracingTags to config.getMergedSpanTags(), which is DD_TAGS + DD_SPAN_TAGS (CoreTracer.java:754, Config.getMergedSpanTags).
• TracingConfigPoller applies RC with maybeOverride(builder::setTracingTags, …), which replaces that whole map (TracingConfigPoller.java:258, :274).
• rebuildTraceConfig (used by AgentTestRunner) seeds tracingTags from config.getGlobalTags() only (CoreTracer.java:1013), so the two setup paths already disagree about whether span tags belong in this map.

I left that row out, so this PR doesn't lock in either behavior. If RC tracing_tags is meant to override DD_TAGS only, the fix belongs with the core change that splits DD_TAGS from span defaults in the config snapshot.

Written by Claude, reviewed by @dougqh

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-19T17:31:21.941993Z	6f54e3e	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[datadog-prod-us1-5]

More details

The added assertions distinguish replacement from merging and verify restoration of DD_TAGS after removing the remote override. The completed static review found no actionable defects.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 6f54e3e}

[datadog-prod-us1-5]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 79.11% (+19.26%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 6f54e3e | 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.92 s	13.86 s	[-0.4%; +1.2%] (no difference)
startup:insecure-bank:tracing:Agent	12.84 s	12.90 s	[-1.1%; +0.1%] (no difference)
startup:petclinic:appsec:Agent	17.06 s	16.95 s	[-0.3%; +1.7%] (no difference)
startup:petclinic:iast:Agent	16.87 s	17.04 s	[-1.8%; -0.2%] (maybe better)
startup:petclinic:profiling:Agent	16.68 s	16.75 s	[-1.6%; +0.7%] (no difference)
startup:petclinic:sca:Agent	16.98 s	16.80 s	[+0.2%; +2.0%] (maybe worse)
startup:petclinic:tracing:Agent	16.10 s	16.10 s	[-0.8%; +0.9%] (no difference)

Commit: 6f54e3e6 · 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.