fix(tracing): report OTLP endpoint on export failure

[mabdinur]

Description

When native OTLP trace export fails, NativeWriter currently reports its configured Datadog Agent intake URL even though libdatadog attempted the OTLP endpoint. This makes an OTLP protocol or connectivity error look like an Agent fallback.

Use the configured OTLP trace endpoint in failure diagnostics whenever OTLP trace export is active. Agent export diagnostics keep their existing behavior.

The original investigation also exposed a separate protocol mismatch: released versions send OTLP traces over HTTP/JSON, while the repro targeted the collector's gRPC port. HTTP/protobuf and gRPC support are already tracked by #18609, DataDog/libdatadog#2171, and DataDog/libdatadog#2273; this PR does not duplicate those transport changes.

Testing

• scripts/run-tests --venv 1ef5a52 -- -- tests/tracer/test_writer.py -k 'native_writer_reports_otlp_intake_endpoint or native_writer_stores_otlp_endpoint' (Python 3.13; 2 passed)
• scripts/lint checks
• scripts/lint style -- ddtrace/internal/writer/writer.py tests/tracer/test_writer.py
• scripts/lint spelling -- releasenotes/notes/fix-otlp-export-error-endpoint-6e7b7c8f756ef3a7.yaml
• riot run reno lint

Risks

Low. The change only affects the endpoint displayed in trace-export failure diagnostics when an OTLP endpoint is configured. It does not change routing, serialization, or retry behavior.

Additional Notes

The OTLP/DDOT reference and the original handoff document were corrected separately to record that the old port-4317 reproduction was testing an HTTP exporter against a gRPC receiver.

[cit-pr-commenter-54b7da]

Codeowners resolved as

ddtrace/internal/writer/writer.py                                       @DataDog/apm-core-python
releasenotes/notes/fix-otlp-export-error-endpoint-6e7b7c8f756ef3a7.yaml  @DataDog/apm-python
tests/tracer/test_writer.py                                             @DataDog/apm-sdk-capabilities-python @DataDog/apm-core-python

[cit-pr-commenter-54b7da]

Circular import analysis

⚠️ Existing circular imports

There are 3 circular imports that already exist on the base branch and have not been changed by this PR.

ddtrace.trace -> ddtrace._trace.tracer -> ddtrace.internal.debug -> ddtrace.trace
ddtrace -> ddtrace.trace -> ddtrace._trace.tracer -> ddtrace.internal.debug -> ddtrace
ddtrace -> ddtrace.trace -> ddtrace._trace.tracer -> ddtrace.internal.debug -> ddtrace.internal.runtime.runtime_metrics -> ddtrace

[datadog-datadog-us1-prod]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

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

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-08-03 18:57:15

Comparing candidate commit 79a9826 in PR branch codex/fix-otlp-export-error-endpoint with baseline commit 4399c31 in branch main.

Found 0 performance improvements and 3 performance regressions! Performance is the same for 354 metrics, 9 unstable metrics.

scenario:span-start

• 🟥 execution_time [+1.300ms; +1.461ms] or [+8.174%; +9.183%]

scenario:telemetryaddmetric-1-count-metric-1-times

• 🟥 execution_time [+158.177ns; +193.697ns] or [+7.445%; +9.117%]

scenario:tracer-small

• 🟥 execution_time [+30.746µs; +32.316µs] or [+9.516%; +10.001%]

[emmettbutler]

nice fix!

[mabdinur]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-08-05 15:45:16 UTC ℹ️ Start processing command /merge

---

2026-08-05 15:45:21 UTC ℹ️ MergeQueue: pull request added to the queue

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

---

2026-08-05 16:33:53 UTC ℹ️ MergeQueue: This merge request was merged