What causes "HTTP client build" in zeroclaw-labs/zeroclaw?

Ensure CA certificates are present in the deployment image when native-tls is in use.

HTTP client build

Error message

HTTP client build

What it means

NodeTransport::new() builds the HTTP client used for authenticated peer-to-peer node requests (30s timeout, HMAC shared-secret auth) and expects reqwest::Client::builder().build() to succeed. As with error 1533, the only realistic failure is TLS backend initialization failure, which this constructor escalates to a panic.

Source

Thrown at crates/zeroclaw-runtime/src/nodes/transport.rs:77

        .fold(0u8, |acc, (x, y)| acc | (x ^ y))
        == 0
}

// ── Node transport client ───────────────────────────────────────

pub struct NodeTransport {
    http: reqwest::Client,
    shared_secret: String,
    max_request_age_secs: i64,
}

impl NodeTransport {
    pub fn new(shared_secret: String) -> Self {
        Self {
            http: reqwest::Client::builder()
                .timeout(std::time::Duration::from_secs(30))
                .build()
                .expect("HTTP client build"),
            shared_secret,
            max_request_age_secs: 300, // 5 min replay window
        }
    }

    /// Send an authenticated request to a peer node.
    pub async fn send(
        &self,
        node_address: &str,
        endpoint: &str,
        payload: serde_json::Value,
    ) -> Result<serde_json::Value> {
        let body = serde_json::to_vec(&payload)?;
        let timestamp = Utc::now().timestamp();
        let nonce = uuid::Uuid::new_v4().to_string();
        let signature = sign_request(&self.shared_secret, &body, timestamp, &nonce)?;

        let url = format!("https://{node_address}/api/node-control/{endpoint}");

View on GitHub (pinned to 88bb9c8533)

Solutions

Ensure CA certificates are present in the deployment image when native-tls is in use.
Pin one TLS backend (rustls-tls) across all workspace crates to eliminate OpenSSL at runtime.
Verify shared library linkage and OpenSSL versions (ldd, openssl version) after base-image upgrades.
Smoke-test node startup in the target container before enabling clustering.

Example fix

// before (Cargo.toml): one crate uses default-tls, another rustls-tls
// after: unify on rustls
reqwest = { version = "0.12", default-features = false, features = ["rustls-tls", "json"] }

Defensive patterns

Strategy: fallback

Validate before calling

// Startup check before enabling node clustering:
let probe = reqwest::Client::builder()
    .timeout(std::time::Duration::from_secs(30)).build();
anyhow::ensure!(probe.is_ok(), "node transport HTTP client cannot initialize (TLS backend): {:?", probe.err());

Try / catch

let http = match reqwest::Client::builder().timeout(Duration::from_secs(30)).build() {
    Ok(c) => c,
    Err(_) => reqwest::Client::builder().timeout(Duration::from_secs(30)).use_rustls_tls().build()?,
};

Prevention

Unify reqwest TLS features across all workspace crates (prefer rustls-tls).
Verify CA certificates and OpenSSL linkage in the deployment image after every base-image bump.
Probe client construction at node startup and fail with a descriptive error before clustering activates.

When it happens

Trigger: Constructing NodeTransport (i.e. enabling node-to-node transport) in a process whose TLS stack cannot initialize: missing CA store with native-tls, conflicting TLS features pulled in by another dependency, or broken OpenSSL linkage.

Common situations: Clustering ZeroClaw nodes inside minimal or hardened containers; adding SDK dependencies that change reqwest's enabled TLS backend; upgrading the base image to one with an incompatible OpenSSL.

Related errors

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/0a98004aeba4e64e. Report an issue: GitHub.