BoundaryML/baml · critical

Function panicked: {s}

Error message

Function panicked: {s}

What it means

When the async task running call_function_parse_from_c_inner panics, the panic is caught by the catch_unwind-style handler and re-reported as this error to the caller's callback. The message embeds the panic payload string, surfacing an internal Rust crash as a normal error instead of aborting the process.

Source

Thrown at engine/language_client_cffi/src/ffi/functions.rs:214

                allow_stream_types,
                &ctx,
                type_builder.as_ref(),
                client_registry.as_ref(),
                env_vars,
            )
        })) {
            Ok(future) => future.await,
            Err(panic_info) => {
                // Handle the panic case - create an error result
                let error_msg = if let Some(s) = panic_info.downcast_ref::<&str>() {
                    format!("Function panicked: {s}")
                } else if let Some(s) = panic_info.downcast_ref::<String>() {
                    format!("Function panicked: {s}")
                } else {
                    "Function panicked with unknown error".to_string()
                };

                Err(anyhow::anyhow!(error_msg))
            }
        };

        match result {
            Ok(result) => send_result_to_callback(id, !allow_stream_types, &result, runtime),
            Err(e) => {
                send_error_to_callback(id, &e);
            }
        };
    });

    Ok(())
}

/// Extern "C" function that returns immediately, scheduling the async call.
/// Once the asynchronous function completes, the provided callback is invoked.
/// Returns Buffer with InvocationResponse (empty on success, error message on failure).
/// Caller must free with free_buffer().

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Read the embedded panic payload in the message to identify the panicking operation
  2. Upgrade to the latest BAML version — internal panics are usually fixed upstream
  3. File a bug report with the panic message, input text shape, and library versions if it persists
  4. Catch the error at the callback and fall back to re-running without the parse path

Example fix

// before (ignoring error detail)
catch (e) { log(e) }
// after
catch (e) {
  if (String(e).includes("Function panicked")) {
    log("BAML internal panic, report with versions", e);
    result = fallbackParse(rawText);
  }
}
Defensive patterns

Strategy: try-catch

Try / catch

try:
    result = await parse_callback_result()
except Exception as e:
    if 'Function panicked' in str(e):
        log.error('BAML internal panic', exc=e)
        result = fallback_parse(raw_text)
    else:
        raise

Prevention

When it happens

Trigger: Any internal panic during parse execution — downcast failures, assertion failures, index-out-of-bounds in runtime code, or unwrap() on unexpected runtime state while parsing text.

Common situations: Buggy or mismatched native library versions, pathological input text triggering runtime edge cases, or incompatibilities between the compiled runtime and loaded BAML files.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


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