fix(opentelemetry): sync resource name with OTel span name on SetName

[link04]

What does this PR do?

Makes the OTel bridge's SetName also update the Datadog resource name (not just the operation name), so the span name exported over OTLP follows a later SetName call.

Motivation

tracer.Start seeds the DD resource from the initial OTel span name, but SetName only updated the operation name — the resource (and thus the OTLP-exported span name) kept the stale value. Instrumentations like otelhttp create the span before routing ("GET") and call SetName with the low-cardinality route afterwards ("GET /users/{id}"); the exported OTLP span name must follow to match the pure OpenTelemetry SDK.

Independent of DD_TRACE_OTEL_SEMANTICS_ENABLED.

Testing

Adds TestSpanSetNameUpdatesResource. Full ddtrace/opentelemetry suite passes.

APMAPI-2016

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.67%. Comparing base (08a41d6) to head (4e2bd38).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

Files with missing lines	Coverage Δ
ddtrace/opentelemetry/span.go	89.88% <100.00%> (-2.81%)	⬇️

... and 289 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-datadog-prod-us1-2]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 62.99% (+4.30%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 4e2bd38 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-06-12 21:20:19

Comparing candidate commit 4e2bd38 in PR branch maximo/otel-bridge-setname-resource with baseline commit 08a41d6 in branch main.

Found 0 performance improvements and 3 performance regressions! Performance is the same for 294 metrics, 2 unstable metrics, 1 flaky benchmarks without significant changes.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:BenchmarkOTelApiWithCustomTags/otel_api

• 🟥 allocated_mem [+462 bytes; +475 bytes] or [+10.742%; +11.039%]
• 🟥 allocations [+6; +6] or [+15.000%; +15.000%]
• 🟥 execution_time [+923.254ns; +1019.746ns] or [+13.795%; +15.237%]

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

Known flaky benchmarks without significant changes:

• scenario:BenchmarkOTLPTraceWriterFlush

[zacharycmontoya]

For maintainers, this same type of issue was discovered in dd-trace-js where the OtelSpan.updateName API was also incorrectly setting the DD span operation name, where it should be updating the DD span resource name: DataDog/dd-trace-js#8864

[zacharycmontoya]

Yep this change looks correct. In the linked dd-trace-js PR, we replaced the previous "set the operation name" instruction with this new "set the resource name" instruction. Can we do the same here in dd-trace-go?

[zacharycmontoya]

LGTM. Let's see if we can replace the previous "operation name" update entirely since operation name is a DD-only concept

[link04]

@codex review

[Copilot]

Pull request overview

This PR updates the OpenTelemetry bridge span renaming behavior so that calling Span.SetName(...) updates the underlying Datadog resource name (which is what ultimately maps to the OTLP-exported span name), rather than changing the Datadog operation name.

Changes:

• Update (*span).SetName to write ext.ResourceName (resource) instead of ext.SpanName (operation).
• Adjust existing TestSpanSetName expectations to validate resource rename behavior and unchanged DD-computed operation name.
• Add a new regression test covering a common HTTP route-renaming scenario (e.g., "GET" → "GET /users/{id}").

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
ddtrace/opentelemetry/span.go	Make SetName update Datadog resource name to keep OTLP span name in sync with OTel renames.
ddtrace/opentelemetry/span_test.go	Update assertions for the new mapping and add coverage for post-start span renames.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: 4e2bd38bf2

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[link04]

Superseded by #4889. Per the team discussion (and matching the dd-trace-js decision), the SetName → resource-name change is a breaking change for a minor release — it shifts RED metrics — so it's now gated behind DD_TRACE_OTEL_SEMANTICS_ENABLED in #4889 rather than changing the default. The change (and Zach's "replace the operation-name update entirely" feedback) has been moved there, gated and tested in both flag states. Closing in favor of #4889.