MongoDB connector v2.0.1 crash-loops on DDN cloud: tracing init panics with NoHttpClient (ndc-sdk v0.9.0 / opentelemetry-otlp 0.31 feature conflict)

Component

Other connectors → c/ddn-ndc-hub (root cause is in hasura/ndc-sdk-rs v0.9.0, manifests in hasura/ndc-mongodb v2.0.1)

What is the current behaviour?

Deploying hasura/mongodb v2.0.1 to DDN cloud fails — the connector container panics during startup and crash-loops, so the connector build never goes healthy:

thread 'main' (1) panicked at .../ndc-sdk-0.9.0/src/default_main.rs:228:6:
Unable to initialize tracing: NoHttpClient
Container called exit(101).

The same connector runs fine locally, and v1.8.4 works in both environments.

What is the expected behaviour?

The connector starts and serves traffic on DDN cloud. A tracing-export problem should arguably degrade gracefully rather than panic the process.

How to reproduce the issue?

1. ddn connector init mydb --hub-connector hasura/mongodb:v2.0.1 -i with any MongoDB source
2. ddn supergraph build create and deploy to a DDN cloud project
3. Connector build fails; runtime logs show the panic above

Please provide any traces or logs that could help here.

2026-06-05T15:20:20.995495Z: thread 'main' (1) panicked at /nix/store/...-vendor-cargo-deps/.../ndc-sdk-0.9.0/src/default_main.rs:228:6:
2026-06-05T15:20:20.995516Z: Unable to initialize tracing: NoHttpClient
2026-06-05T15:20:21.582967111Z: Container called exit(101).

Root cause (verified against published sources):

1. ndc-sdk v0.9.0's workspace Cargo.toml enables reqwest-client on opentelemetry-otlp = "0.31" without default-features = false. opentelemetry-otlp 0.31.0's default features include reqwest-blocking-client, so both reqwest client features end up enabled (confirmed: ndc-mongodb v2.0.1's Cargo.lock pins opentelemetry-otlp 0.31.0).
2. In opentelemetry-otlp 0.31.0 (src/exporter/http/mod.rs:152-193), default HTTP client selection uses three mutually exclusive #[cfg(all(...))] blocks, each requiring the other client features to be off. With both reqwest features on, all three blocks are excluded at compile time, http_client stays None, and line 195 returns ExporterBuildError::NoHttpClient. (0.31.1 is byte-identical here.)
3. init_tracing in crates/sdk/src/tracing.rs only takes the .with_http() path when OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf; unset, it defaults to .with_tonic() (gRPC), which is unaffected. DDN cloud evidently sets http/protobuf — the panic proves the HTTP path was taken there — which is why this only reproduces on cloud deploys.
4. default_main.rs:228 converts the error to a panic via .expect("Unable to initialize tracing").

Any possible solutions/workarounds you're aware of?

Fix (in hasura/ndc-sdk-rs): upgrade opentelemetry-otlp to 0.32.0, which replaced the mutually exclusive cfg blocks with priority-based, feature-additive selection (see open-telemetry/opentelemetry-rust#2994 — the 0.32.0 source comments this fix directly). Minimal alternative on 0.31: add default-features = false to the dependency. Connectors (e.g. ndc-mongodb) then need a release built against the fixed SDK.

Workarounds: pin hasura/mongodb:v1.8.4 (uses opentelemetry-otlp 0.15, unaffected). Forcing OTEL_EXPORTER_OTLP_PROTOCOL=grpc should bypass the broken path, but unverified whether DDN cloud allows overriding it.

Keywords

NoHttpClient, ndc-mongodb, ndc-sdk, opentelemetry-otlp, tracing panic, connector deploy failure, exit 101, reqwest-blocking-client