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
- 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.
- 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.
- Verify you pass the correct `TensorStatus` to `get_handle`/`get_tensor_handle` (ReadOnly vs ReadWrite vs NotInit) in custom BackendIr implementations.
- 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
- Call take_error() before consuming tensors in fallible runtimes
- Ensure every executed op registers its output handle before downstream reads
- Use correct TensorStatus (ReadOnly/ReadWrite/NotInit) for each get_handle call
- When integrating a custom backend, test failure injection so NotInit never leaks as a bare panic
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
- Tensor {id:?} was never written: {error}
- SVD fallback failed: {err}
- Quantization scheme is not valid for dtype {other:?}
- Can't store native sub-byte values
- {other:?} doesn't support native packing
AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05).
Data as JSON: /api/errors/f4e3b2c9bca96d6d.
Report an issue: GitHub.