OTel OTLP exporter times out connecting to HTTPS endpoints from compiled binary

[bixu]

Description

When OTEL_EXPORTER_OTLP_ENDPOINT is set to an HTTPS endpoint (e.g., https://api.eu1.honeycomb.io), the bundled @opentelemetry/otlp-exporter-base Node.js HTTPS transport fails to connect within the 10s default timeout. The endpoint is reachable via curl in ~200ms, so the issue is specific to the HttpsClientRequest transport in the compiled Deno binary.

The error is non-blocking — commands complete successfully — but it prevents users from sending traces to HTTPS OTel backends (like Honeycomb) without running a local collector as an intermediary.

Steps to Reproduce

1. Set OTel environment variables pointing to an HTTPS OTLP endpoint:

   export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.eu1.honeycomb.io
   export OTEL_EXPORTER_OTLP_HEADERS="x-honeycomb-team=<key>"

2. Run any swamp command, e.g. swamp repo upgrade
3. After ~10 seconds, observe the timeout error:

   error: Uncaught (in promise) Error: Request timed out
               error: new Error('Request timed out'),
                      ^
       at HttpsClientRequest.<anonymous> (file:///var/folders/.../deno-compile-swamp/.deno_compile_node_modules/localhost/@opentelemetry/otlp-exporter-base/0.57.2/build/src/transport/http-transport-utils.js:87:20)
       at HttpsClientRequest.emit (ext:deno_node/_events.mjs:451:22)
       at IncomingMessageForClient.#tryReturnSocket (node:http:1036:13)
       at async node:http:970:9
   

Expected Behavior

Traces should be exported to the configured HTTPS OTLP endpoint, or the timeout should be handled gracefully without surfacing an uncaught error.

Workaround

• Use a local OTel Collector on http://localhost:4318 to proxy traces to the HTTPS backend
• Or set OTEL_SDK_DISABLED=true to suppress the error (but loses tracing)

Environment

• swamp version: 20260327.005915.0-sha.86500cc2
• OS: macOS (Darwin 25.4.0)
• OTel exporter version: @opentelemetry/otlp-exporter-base 0.57.2 (bundled in compiled binary)

Summary

The bundled Node.js HttpsClientRequest transport in Deno's compiled binary appears unable to complete TLS connections to external HTTPS OTLP endpoints. This may be a Deno Node.js compatibility issue with how the compiled binary handles HTTPS agent connections. The fix would likely involve either catching the timeout error gracefully, switching to Deno's native fetch-based transport, or investigating the TLS handshake behavior in the compiled binary context.

[github-actions]

Hi @bixu, thanks for opening this issue!

We appreciate you taking the time to report it. A maintainer will review it as soon as possible.

In the meantime, please make sure you've included all relevant details (steps to reproduce, expected vs actual behaviour, swamp version, etc.) to help us triage it quickly.

[stack72]

🔍 Triage started — fetching issue context

[stack72]

📋 Classified as bug (high) — The OTel OTLP exporter uses Node.js HttpsClientRequest via @opentelemetry/exporter-trace-otlp-http, which fails in Deno's compiled binary when connecting to HTTPS endpoints. The root cause is a Deno Node.js compat layer issue with HTTPS/TLS in compiled binaries. Two problems: (1) the Node.js HTTP transport doesn't work for HTTPS in compiled binaries, and (2) the timeout error surfaces as an uncaught promise rejection. The fix should switch to Deno's native fetch-based transport and add graceful error handling.

[stack72]

📝 Implementation plan generated (v1) — Replace the Node.js HTTP-based OTLPTraceExporter with a custom fetch-based exporter that uses Deno's native fetch API, and add graceful error handling so tracing failures are always silent. The Node.js HttpsClientRequest transport fails TLS connections in Deno's compiled binary, causing uncaught timeout errors on HTTPS OTLP endpoints like Honeycomb.

[stack72]

🔍 Adversarial review (plan v1)

• ADV-1 [medium/architecture]: The plan references @opentelemetry/otlp-transformer but it's currently only a transitive dependency (via exporter-trace-otlp-http). When we remove exporter-trace-otlp-http from deno.json, we must add otlp-transformer as a direct dependency.
• ADV-2 [low/scope]: The plan doesn't mention updating design/tracing.md, which references @opentelemetry/exporter-trace-otlp-http in its dependencies section. Should be updated to reflect the new fetch-based exporter.
• ADV-3 [low/testing]: The plan mentions a new fetch_otlp_exporter_test.ts but doesn't detail how fetch will be mocked in Deno. The test needs to stub globalThis.fetch to intercept requests.
• ADV-4 [low/risk]: AbortController/signal timeout for fetch should be set conservatively (e.g., 10s) to match the existing behavior and avoid blocking CLI exit. The plan mentions 5-10s but doesn't commit to a value.

✅ No blocking findings — ready for approval

[stack72]

Approved Implementation Plan (v1)

Summary: Replace the Node.js HTTP-based OTLPTraceExporter with a custom fetch-based exporter that uses Deno's native fetch API, and add graceful error handling so tracing failures are always silent. The Node.js HttpsClientRequest transport fails TLS connections in Deno's compiled binary, causing uncaught timeout errors on HTTPS OTLP endpoints like Honeycomb.

DDD Analysis

This change is entirely within the Infrastructure layer (tracing). The new FetchOtlpExporter implements the SpanExporter interface from @opentelemetry/sdk-trace-base, which is a port/adapter boundary. No domain logic is affected. The exporter is a pure infrastructure concern — it serializes spans using @opentelemetry/otlp-transformer and POSTs them via fetch. The otel_init.ts orchestrator swaps the concrete exporter implementation.

Implementation Steps

1. Create a fetch-based OTLP span exporter that uses Deno's native fetch instead of Node.js HttpsClientRequest (risk: Must correctly serialize spans to OTLP JSON format using @opentelemetry/otlp-transformer)
2. Switch otel_init.ts to use the new fetch-based exporter instead of OTLPTraceExporter from @opentelemetry/exporter-trace-otlp-http (risk: Must preserve existing header parsing and endpoint URL construction)
3. Add graceful error handling around shutdown so export failures never surface as uncaught errors (risk: Shutdown must still attempt to flush spans but swallow failures)
4. Remove @opentelemetry/exporter-trace-otlp-http dependency from deno.json since it's no longer needed (risk: Must verify no other code imports from this package)

Files

• src/infrastructure/tracing/fetch_otlp_exporter.ts
• src/infrastructure/tracing/fetch_otlp_exporter_test.ts
• src/infrastructure/tracing/otel_init.ts
• src/infrastructure/tracing/otel_init_test.ts
• main.ts
• deno.json

Testing Strategy

Unit test the FetchOtlpExporter with mocked fetch to verify: correct URL construction, header passing, JSON serialization via otlp-transformer, timeout behavior, graceful error handling (returns FAILED result, never throws). Existing otel_init tests continue to verify initialization logic.

Potential Challenges

• OTLP JSON serialization format must match what collectors expect — use @opentelemetry/otlp-transformer for correctness
• fetch timeouts need to be reasonable (5-10s) so they don't block CLI exit on long commands
• BatchSpanProcessor flush during shutdown may still throw if fetch fails — need to catch at shutdown boundary

Approved via swamp @si/issue-lifecycle