tracel-ai/burn · critical

Cannot get uninitialized handle {id:?}.

Error message

Cannot get uninitialized handle {id:?}.

What it means

`HandleStore::get_handle` in burn-ir panics when the stored handle for a tensor id is `Handle::NotInit` — the id is registered in the store but no backend resource was ever written into it. This is a burn-runtime bookkeeping invariant violation: by the time a consumer requests a handle, the producer operation should have replaced NotInit with an `Existing` (or `Errored`) handle.

Source

Thrown at crates/burn-ir/src/handle.rs:346

            panic!("Tensor {id:?} was never written: {error}");
        }

        let (id, handle) = self
            .take(id)
            .unwrap_or_else(|| panic!("Should have handle for tensor {id:?}"));

        match handle {
            Handle::Existing(handle) => match status {
                TensorStatus::ReadOnly => {
                    self.put(id, Handle::Existing(handle.clone()));
                    handle
                }
                TensorStatus::ReadWrite => handle,
                TensorStatus::NotInit => panic!(
                    "Cannot get uninitialized tensor {id:?}. Tensor exist but with wrong status"
                ),
            },
            Handle::NotInit => panic!("Cannot get uninitialized handle {id:?}."),
            // The backstop for an `errored` count that has drifted below the
            // map: the guard above is gated on it, so a drift would let an
            // errored entry through to here. Not unreachable — reached only
            // when the invariant `put`/`take` maintain has already broken.
            Handle::Errored(error) => panic!("Tensor {id:?} was never written: {error}"),
        }
    }

    /// Get the tensor handle for the given [tensor intermediate representation](TensorIr).
    pub fn get_tensor_handle(&mut self, tensor: &TensorIr) -> TensorHandle<H> {
        TensorHandle {
            handle: self.get_handle(&tensor.id, &tensor.status),
            shape: tensor.shape.clone(),
        }
    }

    /// Get the [float tensor](burn_backend::backend::BackendTypes::FloatTensorPrimitive) corresponding to the
    /// given [tensor intermediate representation](TensorIr).

View on GitHub (pinned to d16f7ba2ed)

Solutions

  1. Look earlier in the execution log for the operation that was supposed to write this tensor id — the NotInit handle means that op never completed its handle registration; fix that root cause first.
  2. Check `take_error`/`has_errors` flow in your custom backend: ensure failed ops register `Handle::Errored` so consumers get the real error instead of NotInit.
  3. Verify you pass the correct `TensorStatus` to `get_handle`/`get_tensor_handle` (ReadOnly vs ReadWrite vs NotInit) in custom BackendIr implementations.
  4. If you maintain the runtime integration, audit the put/take pairing so outputs of every executed op are stored with `Handle::Existing`.
Defensive patterns

Strategy: validation

Validate before calling

// before reading a tensor in a custom integration:
if store.take_error(&tensor_ir).is_some() {
    return Err("producing op failed; tensor never initialized".into());
}
// or probe existence via has_errors()/store introspection before get_handle

Try / catch

let handle = std::panic::catch_unwind(panic::AssertUnwindSafe(|| store.get_handle(&id, &status)))
    .map_err(|_| anyhow!("tensor {id:?} has an uninitialized handle; producer op failed"))?;

Prevention

When it happens

Trigger: Reading a tensor whose handle is still uninitialized: an operation that should have produced the tensor never ran or never registered its output (e.g. a skipped/failed kernel launch that still left the id registered), or a `TensorStatus::NotInit` tensor that is consumed without first being initialized.

Common situations: Kernel/kernel-launch failure silently swallowed earlier in the graph so downstream reads hit NotInit; mismatched TensorStatus in hand-written BackendIr code (registering output as NotInit then reading it); runtime/graph-executor bugs in custom backend integrations.

Related errors


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