What causes "Failed to receive message from websocket: {err:?}" in tracel-ai/burn?

Retry the tensor download; the server connection is gone and must be re-established.

Failed to receive message from websocket: {err:?}

Error message

Failed to receive message from websocket: {err:?}

What it means

While serving tensor downloads on the 'data' channel, the server awaits WebSocket messages; a receive error (connection reset, abnormal close, timeout, protocol violation) panics with the underlying error. Unlike a clean close (which just returns), this is an unexpected transport failure mid-session.

Source

Thrown at crates/burn-communication/src/external_comm.rs:255

            match channel.recv().await {
                Ok(message) => {
                    if let Some(msg) = message {
                        let bytes = msg.data;
                        let msg: ExternalCommMessage = rmp_serde::from_slice(&bytes)
                            .expect("Can deserialize messages from the websocket.");
                        let ExternalCommMessage::TensorRequest(transfer_id) = msg else {
                            panic!("Received a message that wasn't a tensor request! {msg:?}");
                        };

                        let bytes = self.get_exposed_tensor_bytes(transfer_id).await.unwrap();

                        channel.send(Message::new(bytes)).await.unwrap();
                    } else {
                        log::info!("Closed connection");
                        return;
                    }
                }
                Err(err) => panic!("Failed to receive message from websocket: {err:?}"),
            };
        }
        log::info!("[Data Service] Closing connection for download.");
    }
}

View on GitHub (pinned to d16f7ba2ed)

Solutions

Retry the tensor download; the server connection is gone and must be re-established.
Increase idle/read timeouts on any proxy between client and server.
Check network stability (MTU, firewall, keep-alive/ping settings on the WebSocket).
Inspect the {err:?} payload to distinguish reset vs timeout vs protocol error and address accordingly.

Defensive patterns

Strategy: retry

Validate before calling

// Set keep-alive/ping and read timeouts on the socket before serving
let ws = configure_keepalive(ws, Duration::from_secs(30));

Try / catch

// Client retries the whole download on transport failure
match download(addr).await {
    Ok(d) => Ok(d),
    Err(e) => { tokio::time::sleep(Duration::from_secs(1)).await; download(addr).await }
}

Prevention

Enable WebSocket ping/keep-alive to survive idle proxies
Raise proxy/ingress idle timeouts for long transfers
Expect abrupt disconnects; make the client idempotently retry downloads
Log {err:?} to distinguish reset vs timeout vs protocol error

When it happens

Trigger: Client disconnects abruptly (process killed, network drop) during a tensor download; proxy/load-balancer idle timeout closing the socket; WebSocket frame/protocol error raised by the underlying ws implementation.

Common situations: Long downloads across flaky links or mobile networks; Kubernetes ingress with short idle timeouts; clients cancelled mid-transfer (e.g. tokio task aborted) leaving a reset connection.

Related errors

AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05). Data as JSON: /api/errors/4f1e46b0a9e8ac5d. Report an issue: GitHub.