tracel-ai/burn · error

Failed to send download id

Error message

Failed to send download id

What it means

This panic occurs in download_tensor after connecting to a peer server and sending a TensorRequest message containing the transfer id. The expect fires if the websocket send fails, meaning the download cannot even be initiated. Since the module also tolerates peer closure later (recv returns None), this failure indicates the connection broke between open and send.

Source

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

    pub async fn download_tensor(
        &self,
        remote: Address,
        transfer_id: TensorTransferId,
    ) -> Option<TensorData> {
        log::info!("Downloading tensor from {remote:?}");

        let stream = self.get_data_stream(remote).await;
        let mut stream = stream.lock().await;

        // Send the download request with the download id
        let bytes: bytes::Bytes =
            rmp_serde::to_vec(&ExternalCommMessage::TensorRequest(transfer_id))
                .unwrap()
                .into();
        stream
            .send(Message::new(bytes))
            .await
            .expect("Failed to send download id");

        if let Ok(msg) = stream.recv().await {
            let Some(msg) = msg else {
                log::warn!("Received None message from the websocket, closing connection.");
                return None;
            };

            let ExternalCommMessage::Tensor(data) = rmp_serde::from_slice(&msg.data)
                .expect("Can deserialize messages from the websocket.")
            else {
                panic!("Message should have been TensorData")
            };
            return Some(data);
        }
        log::warn!("Closed connection");
        None
    }

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Retry the download after re-establishing the peer connection; the failure is often transient.
2. Verify the peer server is running and accepting tensor requests before downloading.
3. Check for concurrent close() calls racing with in-flight downloads and serialize shutdown.
4. Surface send errors as a proper None/error return instead of panicking, matching the existing recv-None handling.

Example fix

// before
stream.send(Message::new(bytes)).await.expect("Failed to send download id");
// after
stream.send(Message::new(bytes)).await.map_err(|e| {
    log::warn!("failed to send tensor request {transfer_id}: {e}");
    e
})?;

stream.send(Message::new(bytes)).await
    .map_err(|e| { log::warn!("send failed for {transfer_id}: {e}"); e })?;
// caller: retry download once on transient send error

When it happens

Trigger: Calling download_tensor against a peer whose socket dropped right after connect — peer crashed, network reset, or the stream was concurrently closed by another task (e.g. close() draining streams while a download is in flight).

Common situations: Distributed/data-parallel runs where a peer dies mid-tensor-transfer; requesting tensors from a server that is shutting down; unstable network links between containers/nodes.

Related errors

• Failed to close WebSocket stream
• Failed to open remote 'data' channel to {address}: {err:?}.
• Failed to receive message from websocket: {err:?}
• SVD fallback failed: {err}
• Quantization scheme is not valid for dtype {other:?}

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