BoundaryML/baml · error · VmPanic

baml.panics.HostUnavailable

baml.panics.HostUnavailable

Error message

host resource '{resource}' unavailable: {message}

What it means

This panic variant indicates a required host resource is unavailable, typically because the OS entropy source returned an error in a sandboxed runtime. It is deliberately catchable so BAML user code can fall back gracefully rather than aborting the host process.

Solutions

1. Check the sandbox/runtime configuration and ensure the entropy source (getrandom) is available or a custom RNG is wired into the host.
2. Catch baml.panics.HostUnavailable and switch to a deterministic or alternate resource path in BAML code.
3. Fix environment issues: mount/clear access to the OS entropy device or update the sandbox policy to allow the resource.
4. Upgrade the host runtime so required host imports are implemented.

Example fix

// before
let id = rand.uuid(); // panics if entropy unavailable in sandbox
// after
try {
  id = rand.uuid();
} catch e: baml.panics.HostUnavailable {
  id = deterministic_fallback_id();
}

// Check host resource availability at startup where possible
let ok = host.has_resource("entropy");

try {
  let v = rand.uuid();
} catch e: baml.panics.HostUnavailable {
  let v = fallback_id_source();
}

When it happens

Trigger: BAML code requests a host-provided resource (e.g. random entropy via the host interface) and the host reports it unavailable — for example getrandom/OS entropy failing inside a sandbox, WASM runtime without entropy wired up, or a blocked system call.

Common situations: Running BAML in WASM/sandboxed environments where the entropy source (e.g. /dev/urandom, getrandom syscall) is not available or is denied by the sandbox policy; misconfigured runtimes missing host imports.

Related errors

• {0}
• access error
• assertion failed
• BAML Generate failed - Project has errors.
• baml.json.serialize failed

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/aa6a1634f4488cc1. Report an issue: GitHub.

Appendix: source

Thrown at baml_language/crates/bex_vm_types/src/errors.rs:85

    ///
    /// Catchable in user code as `baml.panics.Exit` — patterned after
    /// Python's `SystemExit`: code can intercept it for cleanup or
    /// testing, and if nothing catches it the engine surfaces the code
    /// as `EngineError::Exit` and the host terminates with it.
    ///
    /// BAML `int` is `i64`, so the signal carries the full value the
    /// user wrote; the host narrows to `i32` for `std::process::exit`.
    #[error("baml.sys.exit({code})")]
    Exit { code: i64 },

    /// The graceful-ish way to handle potential OOM errors, instead of hard-crashing.
    #[error("memory allocation failed: {message}")]
    AllocFailure { message: String },

    /// A required host resource is unavailable — e.g. the OS entropy source
    /// returned an error in a sandboxed runtime. Catchable so user code can
    /// fall back gracefully instead of aborting the host process.
    #[error("host resource '{resource}' unavailable: {message}")]
    HostUnavailable { resource: String, message: String },

    /// The right operand of a bigint shift (`<<` / `>>`) was negative.
    /// Catchable because the count is a runtime `bigint` and the type
    /// system can't rule out negative values.
    #[error("negative bit shift: {message}")]
    NegativeBitShift { message: String },

    /// A host callable returned a value of the wrong type, or threw a value
    /// that does not match its declared `throws` contract `E`. Surfaces in
    /// BAML as `baml.panics.HostContractViolation`.
    ///
    /// `class_name` / `language` are populated when the violation arose from
    /// a host throw (echoing the offending host exception's identity) and
    /// `None` when it arose from a wrong-type return (no exception class to
    /// echo).
    #[error("host contract violation: {message} [class={class_name:?}, lang={language:?}]")]
    HostContractViolation {

View on GitHub (pinned to bd85ce9dee)