What causes "Failed to build the tokio runtime" in tracel-ai/burn?

Don't call blocking start() inside an async context — use start_async() and await it from your own runtime

Failed to build the tokio runtime

Error message

Failed to build the tokio runtime

What it means

The server's blocking start() creates a fresh multi-threaded tokio runtime via Runtime::new() and panics if construction fails. This indicates the process cannot create the async runtime (resource limits, platform constraints).

Source

Thrown at crates/burn-remote/src/server/builder.rs:160

                )
                .await;
            }
            #[cfg(feature = "iroh")]
            Channel::Iroh { secret } => {
                crate::transport::iroh::server::start_iroh_async::<B>(
                    *secret,
                    self.devices,
                    self.custom_ops,
                )
                .await;
            }
        }
    }

    /// Start the server, blocking the current thread until shutdown.
    #[cfg(not(target_family = "wasm"))]
    pub fn start(self) {
        let runtime = tokio::runtime::Runtime::new().expect("Failed to build the tokio runtime");
        runtime.block_on(self.start_async());
    }
}

View on GitHub (pinned to d16f7ba2ed)

Solutions

Don't call blocking start() inside an async context — use start_async() and await it from your own runtime
Check ulimits/rlimits (nproc) and container memory limits
Ensure the tokio crate is compiled with the features needed to build a runtime
Run the server on a dedicated OS thread: std::thread::spawn(move || server.start())

Example fix

// before
server.start(); // inside async fn — panics/blocks
// after
#[cfg(not(target_family = "wasm"))]
std::thread::spawn(move || server.start());

Defensive patterns

Strategy: fallback

Validate before calling

// Only call blocking start() outside any async runtime:
assert!(tokio::runtime::Handle::try_current().is_err(),
    "use start_async() inside an existing runtime");

Try / catch

std::thread::spawn(move || server.start())
    .join()
    .map_err(|_| anyhow!("remote server thread panicked building the tokio runtime"))?;

Prevention

Call start_async() from your own tokio runtime instead of blocking start() inside async code
Verify container/ulimit resources allow creating a tokio runtime
Run the server on a dedicated thread when embedding

When it happens

Trigger: Calling ServerBuilder::start() on non-wasm targets when tokio cannot build a runtime — e.g. insufficient memory, exhausted thread limits, or calling within an existing runtime context that forbids blocking.

Common situations: Embedding the blocking server start inside another tokio runtime thread; containers with very low thread/memory limits; exotic platforms lacking required primitives.

Related errors

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