tracel-ai/burn · error

Received a message that wasn't a tensor request! {msg:?}

Error message

Received a message that wasn't a tensor request! {msg:?}

What it means

The server-side data-channel handler expects every incoming message on the 'data' channel to be an `ExternalCommMessage::TensorRequest`. Any other valid message triggers this panic, meaning the connected peer is using the data channel for something other than download requests.

Source

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

        }
    }

    /// Handle incoming connections for downloading tensors.
    pub(crate) async fn handle_data_channel(
        &self,
        mut channel: <P::Server as ProtocolServer>::Channel,
    ) {
        log::info!("[Data Handler] New connection for download.");

        while !self.cancel_token.is_cancelled() {
            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

1. Send only `ExternalCommMessage::TensorRequest` on the 'data' channel from the downloading side.
2. Align burn-communication versions between client and server so the enum variants match.
3. Inspect the {msg:?} debug output in the panic to identify which variant the peer actually sent.

// Server side: ignore rather than panic on unexpected variants
match msg {
    ExternalCommMessage::TensorRequest(id) => serve(id).await,
    other => log::warn!("ignoring non-request message: {other:?}"),
}

fn as_tensor_request(msg: ExternalCommMessage) -> Option<TransferId> {
    match msg { ExternalCommMessage::TensorRequest(id) => Some(id), _ => None }
}

When it happens

Trigger: A client sending TensorData or other ExternalCommMessage variants over the 'data' subprotocol instead of TensorRequest; two clients both opening data channels as servers; protocol/version mismatch causing a different variant to deserialize first.

Common situations: Miswired client code that uploads tensors on the data channel; a burn version mismatch where the message enum layout differs; a proxy duplicating messages across channels.

Related errors

• Message should have been TensorData
• capture tensor operations must run inside CaptureDevice::cap
• capture tensor {} has no initialized value
• seeding is not supported during graph capture
• capture graph {graph_id:?} was not registered

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