Hmbown/CodeWhale · error · anyhow::Error

GET error: {e}

Error message

GET error: {e}

What it means

The same 5-second-bounded preflight GET failed at the transport level: `request.send()` returned a reqwest error `e` within the budget, which is formatted into "GET error: {e}" (crates/tui/src/mcp/http.rs:207). The embedded reqwest error distinguishes the cause — DNS resolution failure, connection refused, TLS error, proxy error, etc. This is a network/request-construction failure, not a timeout (that is error 1056).

Source

Thrown at crates/tui/src/mcp/http.rs:207

            biased;
            _ = cancel.cancelled() => {
                anyhow::bail!("MCP session preflight cancelled after plugin authority changed")
            }
            headers = transport.auth.resolved_headers() => headers?,
        };
        let request = apply_safe_custom_headers(
            with_default_mcp_http_headers(transport.client.get(&transport.url), false),
            &headers,
        );
        let response = tokio::select! {
            biased;
            _ = cancel.cancelled() => {
                anyhow::bail!("MCP session preflight cancelled after plugin authority changed")
            }
            response = tokio::time::timeout(Duration::from_secs(5), request.send()) => {
                response
                    .map_err(|_| anyhow::anyhow!("GET timeout"))?
                    .map_err(|e| anyhow::anyhow!("GET error: {e}"))?
            }
        };

        // Capture session ID from the GET response so subsequent POSTs
        // (including `initialize`) can include it. This is the same
        // header-reading logic that would be hit inside
        // `StreamableHttpTransport::send` for POST responses, but since
        // the GET is sent before any POST we do it here directly.
        if let Some(sid) = response
            .headers()
            .get("Mcp-Session-Id")
            .and_then(|v| v.to_str().ok())
            && transport.session_id.as_deref() != Some(sid)
        {
            let session_ref = crate::utils::redacted_identifier_for_log(sid);
            tracing::debug!(target: "mcp", session = %session_ref, "captured MCP session ID via GET preflight");
            transport.session_id = Some(sid.to_string());
        }

View on GitHub (pinned to 0c42157ee5)

Solutions

  1. Read the embedded `{e}` — 'error trying to connect: dns error' means bad host/VPN, 'Connection refused' means wrong port/service down, TLS errors mean certificate problems.
  2. Verify basic reachability with curl against the same URL; fix the URL/port in the MCP server config if curl also fails.
  3. For self-signed certificates, install the CA locally or serve a publicly-trusted cert (do not disable verification).
  4. Reconnect VPN or fix DNS for internal hostnames; confirm the MCP service is running on the target host.

Example fix

# before
url = "https://mcp.internal.example/mcp"  # 'GET error: error trying to connect: dns error'

# after — fix host/port from the service's actual binding
url = "https://mcp.internal.example:8443/mcp"  # curl -v confirms 200 on this URL
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight the URL the same way before configuring:
let url = reqwest::Url::parse(endpoint)?; // catches malformed URLs early
// curl -v <endpoint> to confirm DNS, port, and TLS all succeed

Try / catch

match connect_streamable_http(&url, &headers).await {
    Ok(t) => t,
    Err(e) if e.to_string().starts_with("GET error:") => {
        // inspect the embedded reqwest cause: dns -> fix host/VPN; refused -> fix port/service; tls -> fix cert
        return Err(e);
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Connecting to an HTTP MCP endpoint whose host does not resolve (typo'd hostname), refuses connections (service down / wrong port), presents an invalid/self-signed certificate, requires a client proxy that rejects the request, or redirects improperly. Any `reqwest::Error` from the preflight GET maps here.

Common situations: Wrong URL or port in the MCP server config; DNS not resolving internal hostnames (VPN down); self-signed certs in dev environments; endpoint moved or decommissioned; corporate TLS-inspecting proxy breaking the handshake; IPv6-only misconfiguration.

Related errors


AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/69769347dc1313ab. Report an issue: GitHub.