tracel-ai/burn · error

Can serialize RemoteMessage::Init

Error message

Can serialize RemoteMessage::Init

What it means

This panic fires during the client-to-server handshake when MessagePack serialization of the single-element `RemoteMessage::Init` batch fails. The library treats this as an invariant that can never legitimately fail — `SessionInit` contains only serializable plain data (session id, device index, auth token bytes) — so the result is unwrapped with an expect rather than propagated. Hitting it indicates a broken build or a corrupted/incompatible rmp_serde dependency, not a user mistake.

Source

Thrown at crates/burn-remote/src/client/service.rs:170

        executor
            .block_on(open_channels(endpoint))
            .unwrap_or_else(|err: String| panic!("{err}"))
    }

    /// Send the session-init handshake on both streams and wait for the device settings the
    /// server replies with on the response stream. Both streams carry the same `Vec<RemoteMessage>`
    /// wire format; the handshake is just a single-element batch.
    async fn handshake_async(
        request: &mut SubmitChannel,
        response: &mut ResponseChannel,
        endpoint: &RemoteEndpoint,
        session_id: SessionId,
        device_index: u32,
    ) -> (DeviceSettings, u32) {
        let init_bytes: bytes::Bytes = rmp_serde::to_vec(&vec![RemoteMessage::Init(
            SessionInit::new(session_id, device_index, endpoint.authorization().to_vec()),
        )])
        .expect("Can serialize RemoteMessage::Init")
        .into();

        let result: Result<(DeviceSettings, u32), String> = async {
            request.send(init_bytes).await?;

            let msg = response
                .recv()
                .await?
                .expect("Server disconnected during initialization");
            let reply: TaskResponse =
                rmp_serde::from_slice(&msg).expect("Can deserialize init handshake payload");

            match reply.content {
                TaskResponseContent::Init(SessionInfo {
                    version,
                    settings,
                    device_count,
                    ..

View on GitHub (pinned to d16f7ba2ed)

Solutions

  1. Run `cargo update -p rmp-serde` (or align rmp-serde versions with `cargo tree -d -p rmp-serde`) so the dependency matches what burn-remote was built against.
  2. Verify you are on an unmodified, matching version of burn/burn-remote — if you forked it, check any fields you added to SessionInit or RemoteMessage are serde-serializable.
  3. Rebuild from scratch (`cargo clean && cargo build`) to rule out a stale build artifact.
  4. If reproducible, file a bug with burn including the rmp_serde error details.

Example fix

// before (fork with non-serializable field)
struct SessionInit { id: SessionId, device: u32, auth: Vec<u8>, custom: Box<dyn Any> }
// after
#[derive(serde::Serialize, serde::Deserialize)]
struct SessionInit { id: SessionId, device: u32, auth: Vec<u8> }
Defensive patterns

Strategy: try-catch

Validate before calling

// Panics are not catchable via Result; validate dependency setup instead:
// cargo tree -d -p rmp-serde  (must show exactly one version)
// Also verify SessionInit fields in any fork derive Serialize/Deserialize.

Try / catch

// This expect panics; catch with std::panic::catch_unwind only around service init:
let result = std::panic::catch_unwind(|| RemoteService::init(...));
if result.is_err() { eprintln!("burn-remote init failed (serialization invariant)"); }

Prevention

When it happens

Trigger: Only when rmp_serde::to_vec fails to serialize `vec![RemoteMessage::Init(SessionInit::new(...))]` during `handshake_async`; in practice this never happens with valid data and would require a dependency mismatch or a non-serializable field introduced by a custom fork.

Common situations: Mixing incompatible versions of `rmp-serde` / `bytes` via cargo dependency resolution; using a patched fork of burn-remote that added non-serializable fields to `SessionInit` or `RemoteMessage`; exotic no_std/target builds where a serde impl is misconfigured.

Related errors


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