fix(trace-stats): read OTel HTTP names for the status and method dimensions

[link04]

What does this PR do?

Preserves OpenTelemetry HTTP semantics in libdatadog's in-process consumers and OTLP output.

Trace stats and OTLP trace metrics

• reads canonical Datadog HTTP method/status keys first, then falls back to http.request.method and http.response.status_code
• accepts valid numeric or string status values without allowing empty, malformed, non-finite, or non-integral values to shadow a valid fallback
• emits OTel trace-metric dimensions for method, status, route, span name, and kind
• leaves successful status.code unset and prevents additional tags from overriding the computed status

HTTP tag handling

libdatadog does not rename tracer span tags in this PR. It accepts the Datadog and OpenTelemetry names below as equivalent inputs to trace-stat aggregation and emits the canonical OpenTelemetry name in OTLP trace metrics.

Concept	Datadog span input	OpenTelemetry span input	OTLP trace-metric output
HTTP method	http.method	http.request.method	http.request.method
HTTP response status	http.status_code	http.response.status_code	http.response.status_code as an integer
Span error status	Span error flag	Span error flag	status.code=STATUS_CODE_ERROR for errors; omitted for successful spans

When both naming variants are present, the Datadog name wins. Empty or malformed values fall through to the alternate name instead of hiding a valid value.

OTLP sampled flags

Sampling priority is a trace-level decision, but v0.4/v0.5 inputs may attach _sampling_priority_v1 to only one span. The mapper now uses the same first-priority policy as drop_chunks, treats a missing priority as sampled, and applies one decision to every span in the chunk.

This prevents sampled traces from exporting child spans with flags=0 and keeps OTLP flags consistent with the existing chunk-retention policy.

No public signature, wire-format, setting, or environment-variable change is introduced.

Motivation

Under DD_TRACE_OTEL_SEMANTICS_ENABLED, spans use OTel HTTP names before client-side stats are computed. Stats and OTLP metrics must preserve those dimensions, and all spans in an exported trace must carry the same sampled decision.

Companion changes:

• Historical full Python PR: DataDog/dd-trace-py#19501
• Native Python stack: foundation #20008, client #20009, server #20010
• DataDog/dd-trace-js#9688
• DataDog/system-tests#7455

Testing

• cargo fmt --check -p libdd-trace-utils
• mapper unit tests: 31 passed
• OTLP trace-exporter integration tests: 3 passed
• trace-stats tests: 43 passed

End-to-end re-run from libdatadog head 0ed7fd9bd with the final Python server layer and companion system tests:

Scenario	Result
OTEL_SEMANTICS_OTLP_TRACE_METRICS	4 passed
OTEL_SEMANTICS_OTLP_SAMPLING_RULES	2 passed

[pr-commenter]

Benchmarks

Comparison

Benchmark execution time: 2026-09-02 15:32:52

Comparing candidate commit 6a1814e in PR branch maximo/otel-semantics-tags with baseline commit edde9da in branch main.

Found 1 performance improvements and 2 performance regressions! Performance is the same for 138 metrics, 0 unstable metrics.

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:otlp/e2e_protobuf/1x1000

• 🟩 execution_time [-156.023µs; -154.769µs] or [-4.397%; -4.361%]

scenario:otlp/encode_json/1x1000

• 🟥 execution_time [+105.108µs; +105.727µs] or [+6.410%; +6.448%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/8

• 🟥 execution_time [+15.032ns; +15.269ns] or [+4.261%; +4.328%]

Benchmark execution time: 2026-09-02 15:31:12

Comparing candidate commit 6a1814e in PR branch maximo/otel-semantics-tags with baseline commit edde9da in branch main.

Found 0 performance improvements and 4 performance regressions! Performance is the same for 71 metrics, 10 unstable metrics.

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:glob_matcher/ascii_wildcard_backtrack_match/wall_time

• 🟥 execution_time [+20.261ns; +20.278ns] or [+55.012%; +55.060%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/wall_time

• 🟥 execution_time [+14.717ns; +14.742ns] or [+35.982%; +36.043%]

scenario:glob_matcher/ascii_wildcard_question_match/wall_time

• 🟥 execution_time [+17.395ns; +17.415ns] or [+47.262%; +47.317%]

scenario:glob_matcher/ascii_wildcard_star_match/wall_time

• 🟥 execution_time [+19.833ns; +19.852ns] or [+53.820%; +53.874%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	91.28 MB	91.30 MB	+.02% (+21.17 KB) 🔍
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.45 MB	8.45 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.38 MB	11.38 MB	0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	102.59 MB	102.61 MB	+.01% (+20.86 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	27.32 MB	27.33 MB	+.03% (+9.00 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	96.08 KB	96.08 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	185.36 MB	185.41 MB	+.02% (+56.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	803.66 MB	805.24 MB	+.19% (+1.57 MB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	9.01 MB	9.01 MB	+.01% (+1.00 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	96.08 KB	96.08 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	26.20 MB	26.21 MB	+.02% (+8.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	52.21 MB	52.22 MB	+.01% (+7.74 KB) 🔍

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	23.81 MB	23.82 MB	+.03% (+8.50 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	97.58 KB	97.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	190.39 MB	190.43 MB	+.02% (+40.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	788.17 MB	788.61 MB	+.05% (+448.29 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.96 MB	6.96 MB	+.02% (+2.00 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	97.58 KB	97.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	28.18 MB	28.18 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	49.69 MB	49.70 MB	+.01% (+8.72 KB) 🔍

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	81.43 MB	81.45 MB	+.02% (+18.46 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	9.41 MB	9.41 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	97.20 MB	97.22 MB	+.01% (+18.76 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.46 MB	11.46 MB	0% (0 B) 👌

[datadog-datadog-prod-us1]

✅ All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 99.81%
• Overall Coverage: 77.01% (+0.11%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 6a1814e | Docs | View more details | Give us feedback!}

[ichinaski]

Changes regarding the OTel tags for method and status_code extraction look good.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6219f24678

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

[bm1549]

Left a few small comments about cross-repo consistency that I think should be considered. Otherwise LGTM

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-09-02 16:55:48 UTC ℹ️ Start processing command devflow:merge

---

2026-09-02 16:55:54 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 49m (p90).

---

2026-09-02 17:31:47 UTC ℹ️ MergeQueue: This merge request was merged