tinyhumansai/openhuman · error

failed to build integration HTTP client

Error message

failed to build integration HTTP client

What it means

Panic payload on the reqwest client build for IntegrationClient (/agent-integrations/* traffic): after sanitizing the backend URL and selecting the platform TLS backend (schannel on Windows, rustls elsewhere) plus product-identity headers, builder.build() failed. Client construction is deterministic from config, so failure means malformed proxy/TLS configuration; the expect aborts client creation.

Source

Thrown at src/openhuman/integrations/client.rs:344

        // to fix up the input so the regression is observable in logs.
        let backend_url = sanitize_backend_url(&backend_url);

        // Platform-appropriate TLS backend — see [`crate::openhuman::util::tls`].
        // Windows uses schannel (native-tls) to honor the OS cert store;
        // macOS / Linux keep rustls which avoids the OpenSSL runtime dep and
        // has historically been more reliable on staging TLS handshakes.
        //
        // `/agent-integrations/*` is backend traffic like any other, so it
        // carries the same product identity as `BackendOAuthClient`. The SDK
        // merges its own default headers into every request, so `http_client`
        // needs nothing beyond `with_default_headers` below.
        let product_headers = crate::api::product::product_identity_headers();
        let http_client = crate::openhuman::util::tls::tls_client_builder()
            .http1_only()
            .timeout(Duration::from_secs(60))
            .connect_timeout(Duration::from_secs(15))
            .build()
            .expect("failed to build integration HTTP client");
        let sdk = TinyHumansClient::new(&backend_url)
            .with_token(Some(auth_token.clone()))
            .with_http_client(http_client.clone())
            .with_default_headers(product_headers);
        // `download_client` deliberately does NOT carry the product identity.
        // Its one caller (`get_bytes`) fetches
        // `/agent-integrations/file-storage/files/{id}/download`, which answers
        // a 302 to a presigned S3 URL. reqwest follows redirects by default and
        // strips only *sensitive* headers (Authorization, Cookie, …) when the
        // host changes — a custom header like `x-sdk-name` survives the hop, so
        // tagging this transport would disclose the product identity to the
        // storage provider. Attaching it per-request would not help: redirected
        // requests carry the original request headers too.
        //
        // The lost attribution is deliberate and cheap: the header cannot be
        // scoped to the first hop without hand-rolling redirect following, and
        // any session that downloads a file has already made SDK-path calls that
        // are tagged.

View on GitHub (pinned to 7491200858)

Solutions

1. Inspect proxy and TLS settings in the effective config for malformed values
2. Verify the schannel/rustls feature set matches the platform build
3. Replace the expect with error propagation so integrations degrade gracefully when the client cannot build

When it happens

Trigger: Thrown at src/openhuman/integrations/client.rs:344 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/0e9578d37cf9bc74. Report an issue: GitHub.