diem/diem · error · StreamError

Transport error: {0}

Error message

Transport error: {0}

What it means

`StreamError::TransportError(String)` reports a failure in the underlying transport carrying the streaming RPC (e.g., the WebSocket/network layer), with details in the carried string. It means message delivery failed for reasons outside stream logic itself — connection resets, protocol errors, I/O failures.

Source

Thrown at json-rpc/src/stream_rpc/errors.rs:14

// Copyright (c) The Diem Core Contributors
// SPDX-License-Identifier: Apache-2.0

use thiserror::Error;

#[derive(Debug, Error)]
pub enum StreamError {
    #[error("Could not convert {0} to string")]
    CouldNotStringifyMessage(String),
    #[error("Client#{0} is closed")]
    ClientAlreadyClosed(u64),
    #[error("Received disconnect request message from client")]
    ClientWantsToDisconnect,
    #[error("Transport error: {0}")]
    TransportError(String),
}

View on GitHub (pinned to fc4714a8ea)

Solutions

  1. Read the carried string to identify the transport-layer cause, then address that specific issue.
  2. Implement client-side reconnection with resubscribe/backoff for streams.
  3. Configure idle keep-alives/timeouts on proxies/load balancers to keep long streams alive.
  4. Verify network/TLS configuration between client and node; test connectivity to the RPC port.
Defensive patterns

Strategy: retry

Validate before calling

// Pre-flight connectivity check to the RPC endpoint before opening streams
let addr = format!("{}:{}", host, port);
std::net::TcpStream::connect(&addr).expect("RPC endpoint unreachable before streaming");

Try / catch

match open_stream(&endpoint) {
    Err(StreamError::TransportError(msg)) => {
        warn!("transport failure: {} — retrying with backoff", msg);
        backoff_retry(|| open_stream(&endpoint), 5);
    }
    Err(e) => handle_other(e),
    Ok(stream) => pump(stream),
}

Prevention

When it happens

Trigger: The socket/transport write or read fails while streaming messages: peer reset the connection, network interruption, TLS handshake failure, or the transport layer returned a protocol-level error.

Common situations: Unstable client networks dropping WebSockets mid-stream; load balancers with short idle timeouts killing long-lived streams; server restarts severing all client transports.

Related errors


AI-assisted analysis of diem/diem@fc4714a8ea (2026-09-04). Data as JSON: /api/errors/29e2422c629216c7. Report an issue: GitHub.