Distributed operations are not supported for device {other:?

Error message

Distributed operations are not supported for device {other:?}

What it means

A distributed-operation macro in burn-dispatch matched a DispatchDevice variant it cannot handle — the catch-all `other` arm panics with 'Distributed operations are not supported for device {other:?}'. The macro is generated per concrete backend, and any device type outside the enumerated backends (e.g. a distributed/multi-node device variant) reaches the fallback arm. This is a compile-time-generated dispatch, so the panic means the operation was invoked on a device kind the backend macro set does not cover.

Source

Thrown at crates/burn-dispatch/src/macros.rs:74

            #[cfg(feature = "autodiff")]
            $crate::DispatchDevice::Autodiff(inner) => {
                // Recursively dispatch on inner
                dispatch_device_arms!(
                    @autodiff
                    &**inner,
                    |$inner| $body;
                    $([$Backend, $cfg]),*
                )
            },
            $(
                #[cfg($cfg)]
                $crate::DispatchDevice::$Backend($inner) => {
                    type B = $crate::backends::$Backend;
                    $body
                }
            )*
            #[allow(unreachable_patterns)]
            other => panic!("Distributed operations are not supported for device {other:?}"),
        }
    };
    (
        @autodiff
        $device:expr,
        |$inner:ident| $body:expr;
        $([$Backend:ident, $cfg:meta]),*
    ) => {
        match $device {
            $(
                #[cfg($cfg)]
                $crate::DispatchDevice::$Backend($inner) => {
                    type B = $crate::backends::Autodiff<$crate::backends::$Backend>;
                    $body
                }
            )*
            $crate::DispatchDevice::Autodiff(_) => unreachable!("Autodiff should not wrap an autodiff device."),
            #[allow(unreachable_patterns)]

View on GitHub (pinned to d16f7ba2ed)

Solutions

Run distributed operations on a device variant that the dispatch macro supports (one of the enumerated backends), not on a distributed/custom DispatchDevice variant.
Check how the device was constructed — a DispatchDevice::Distributed or similar must not reach single-backend operation macros; convert or extract the inner backend device first.
If writing generic code, match the device and route distributed variants to a distributed-aware API before invoking backend macros.
Update burn if you believe the variant should be supported — the macro arm list grows per release.

Example fix

// before
device.dispatch(distributed_op) // device = DispatchDevice::Distributed(..) -> panic

// after
match device {
    DispatchDevice::Distributed(d) => distributed_runtime::run(d),
    _ => device.dispatch(op),
}

Defensive patterns

Strategy: type-guard

Validate before calling

fn supports_distributed(device: &DispatchDevice) -> bool {
    !matches!(device, DispatchDevice::Distributed(_) | DispatchDevice::Remote(_))
}

Type guard

fn is_backend_device(d: &DispatchDevice) -> Option<&DispatchDevice> {
    match d {
        DispatchDevice::Candle(_) | DispatchDevice::NdArray(_) | DispatchDevice::Flex(_) => Some(d),
        _ => None, // distributed/unhandled variants rejected before dispatch
    }
}

Try / catch

// panic is not catchable idiomatic Rust; guard instead
assert!(matches!(device, DispatchDevice::Candle(_) | _), "use a supported backend device");

Prevention

Never pass distributed device variants into single-backend operation macros.
Centralize device handling in one match that routes distributed variants separately.
Keep dispatch macro usage in sync with the device variants your app can produce.

When it happens

Trigger: Invoking a distributed operation (via the macro at macros.rs:74) while the active DispatchDevice is a variant not enumerated by the macro's backend list — e.g. a distributed device struct passed where a single-backend device is expected. The 'USED AT' call sites (CheckpointerBuilder::extend/infer in burn-autodiff) show the generated code flowing through checkpoint builder construction on autodiff-wrapped devices.

Common situations: Mixing single-node backends with distributed training setups; enabling distributed features but running on a device that resolves to a non-backend variant; library code (like the autodiff checkpointer) being generic over devices while the macro only supports concrete backends.

Related errors

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