[mhlidd]

What Does This Do

When a remote config change updates the global tags (DD_TAGS), traces with the old and new tags are now exported in the same OTLP payload, each under its own resource carrying its tags. Previously, every switch between tag sets forced the current payload to be flushed.

This PR also slightly refactors work from #12985 to fit in better with the dedupe work from #13065.

Motivation

After a remote config tag change, traces started before the change (such as long-lived traces still sending partial flushes) keep their old global tags and arrive interleaved with new traces. Flushing on every switch could turn one batch into many small HTTP requests. OTLP already allows several ResourceSpans per request, so the tag change no longer needs to cut the payload.

Additional Notes

• Follows Write global tags once on the OTLP trace resource #13065, which writes global tags once on the OTLP trace resource. This PR also merges OtlpSpanTags into OtlpSpanAttributes as a nested Writer (237ae23), a follow-up cleanup that didn't make it into Write global tags once on the OTLP trace resource #13065.
• Both the JSON and protobuf collectors cache the current and previous resource, so alternating between the old and new tags swaps them instead of rebuilding each time.
• Trade-off: if tag sets alternate trace by trace, each switch writes the resource attributes again. That is still cheaper than one request per switch.
• Process tags are now written on the first span of each resource rather than once per payload.

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
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: N/A

🤖 Generated with Claude Code

[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-28T19:40:15.978892Z	5142b32	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-datadog-prod-us1-2]

🎯 Code Coverage (details)
• Patch Coverage: 96.34%
• Overall Coverage: 60.75% (+1.24%)

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

[datadog-datadog-prod-us1-2]

More details

Resource transitions, framing, and trace-boundary metadata appear consistent in both OTLP encodings when tag sets alternate. Runtime behavior was not exercised.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 5142b32}

[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.79 s	14.70 s	[-0.2%; +1.4%] (no difference)
startup:insecure-bank:tracing:Agent	13.62 s	13.68 s	[-1.2%; +0.3%] (no difference)
startup:petclinic:appsec:Agent	17.88 s	17.65 s	[+0.4%; +2.2%] (maybe worse)
startup:petclinic:iast:Agent	17.65 s	17.70 s	[-1.2%; +0.6%] (no difference)
startup:petclinic:profiling:Agent	17.65 s	17.35 s	[+0.4%; +3.0%] (maybe worse)
startup:petclinic:sca:Agent	17.87 s	17.84 s	[-0.7%; +1.0%] (no difference)
startup:petclinic:tracing:Agent	16.68 s	16.80 s	[-1.8%; +0.3%] (no difference)

Commit: 5142b32f · 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.

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-10-29 13:27:11 UTC ℹ️ Start processing command /merge

---

2026-10-29 13:27:15 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 2h (p90).

---

2026-10-29 14:12:36 UTC ❌ MergeQueue: The build pipeline contains failing jobs for this merge request

Build pipeline has failing jobs for ba7a8cd:

• test_inst: [semeru11, 4/8]

⚠️ Do NOT retry failed jobs directly (why?).

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

Details

Since those jobs are not marked as being allowed to fail, the pipeline will most likely fail.
Therefore, and to allow other builds to be processed, this merge request has been rejected and the pipeline got canceled.

[dd-octo-sts]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-10-29 14:28:03 UTC ℹ️ Start processing command /merge

---

2026-10-29 14:28:07 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 2h (p90).

---

2026-10-29 15:38:58 UTC ℹ️ MergeQueue: This merge request was merged