fix(native-spans): keep OTLP export when a custom lookup is configured

The custom-`lookup` guard did not exclude OTLP, so
`OTEL_TRACES_EXPORTER=otlp` plus a configured `lookup` selected the JS
pipeline, which builds an `AgentExporter`. The OTLP endpoint was never
configured and every span went to the Datadog agent instead of the
collector.

OTLP export lives in libdatadog, so the JS pipeline cannot do it at all.
Give OTLP precedence, exactly as the Lambda pipeline already does, and
warn that the `lookup` cannot be honoured rather than dropping it in
silence.

Reported by Codex review as P1, against the commit that added the guard.

Author: bengl

packages/dd-trace/src/opentracing/tracer.js

@@ -121,11 +121,22 @@ class DatadogTracer {
     //
     // CI Visibility and electron pick their own exporters below and neither goes
     // through the native transport, so they are unaffected by this.
+    //
+    // OTLP is excluded for a harder reason: OTLP export lives in libdatadog, so
+    // the JS pipeline cannot do it at all. Routing there would quietly ship every
+    // span to the agent instead of the configured collector, which is a worse
+    // failure than resolving the collector with the system resolver. OTLP keeps
+    // precedence exactly as it does for the Lambda pipeline above, and the
+    // unhonoured `lookup` is announced rather than dropped in silence.
     const lookupOrigin = typeof config.getOrigin === 'function' ? config.getOrigin('lookup') : 'default'
-    const useCustomLookup = typeof config.lookup === 'function' &&
-      lookupOrigin !== 'default' &&
+    const hasCustomLookup = typeof config.lookup === 'function' && lookupOrigin !== 'default'
+    if (hasCustomLookup && useOtlpExporter) {
+      log.warn('OTLP trace export cannot honour a custom `lookup`; resolving the collector with the system resolver')
+    }
+    const useCustomLookup = hasCustomLookup &&
       !config.isCiVisibility &&
-      !useElectronExporter
+      !useElectronExporter &&
+      !useOtlpExporter
     const unsupportedApmExporter = configuredExporter &&
       configuredExporter !== exporters.AGENT &&
       !useElectronExporter &&

packages/dd-trace/test/opentracing/tracer.spec.js

@@ -376,6 +376,29 @@ describe('Tracer', () => {
     sinon.assert.calledOnce(NativeSpansInterface)
   })
 
+  it('keeps OTLP export when a custom DNS lookup is also configured', () => {
+    // OTLP export lives in libdatadog, so the JS pipeline cannot do it at all.
+    // Routing there for the sake of `lookup` would quietly ship every span to the
+    // agent instead of the configured collector - a worse failure than resolving
+    // the collector with the system resolver.
+    config.OTEL_TRACES_EXPORTER = 'otlp'
+    config.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT = 'http://collector.example:4318/v1/traces'
+    config.lookup = (hostname, options, callback) => callback(null, '127.0.0.1', 4)
+    config.getOrigin = sinon.stub().withArgs('lookup').returns('code')
+    Tracer = loadTracer()
+
+    tracer = new Tracer(config)
+
+    assert.strictEqual(tracer._useJsSpans, false)
+    sinon.assert.notCalled(AgentExporter)
+    sinon.assert.calledWith(NativeExporter, config, prioritySampler, nativeSpansInstance)
+    // The dropped `lookup` must be announced, not silently ignored.
+    sinon.assert.calledWith(
+      log.warn,
+      'OTLP trace export cannot honour a custom `lookup`; resolving the collector with the system resolver'
+    )
+  })
+
   it('writes traces to stdout when OTLP is requested in a Lambda with no local agent', () => {
     // useLambdaJsPipeline excludes OTLP, so this path is reached through the
     // missing-libdatadog degrade branch — it must still honour the no-local-agent