BoundaryML/baml · error

Arrow types are not supported in CFFI

Error message

Arrow types are not supported in CFFI

What it means

Hard capability guard in the CFFI type encoder: the value being encoded carries an Arrow-type IR node, which the CFFI surface cannot represent. The CFFI boundary only supports the non-arrow type universe; reaching this panic means a type that only the newer arrow pipeline understands was handed to the legacy CFFI encoder — an integration mismatch, not user input.

Source

Thrown at engine/language_client_cffi/src/ctypes/baml_type_encode.rs:83

                value: Some(Box::new(
                    WithIr {
                        value,
                        lookup,
                        mode,
                        curr_type,
                    }
                    .encode(),
                )),
                checks,
            }))
        } else {
            match curr_type {
                TypeGeneric::Top(_) => panic!(
                    "TypeGeneric::Top should have been resolved by the compiler before code generation. \
                    This indicates a bug in the type resolution phase."
                ),
                TypeGeneric::Tuple(_, _) => panic!("Tuple types are not supported in CFFI"),
                TypeGeneric::Arrow(_, _) => panic!("Arrow types are not supported in CFFI"),
                TypeGeneric::Primitive(type_value, _) => type_value.encode(),
                TypeGeneric::Literal(literal_value, _) => cType::LiteralType(literal_value.encode()),
                TypeGeneric::Enum {
                    name,
                    dynamic: _,
                    meta: _,
                } => cType::EnumType(CffiFieldTypeEnum { name }),
                TypeGeneric::Class {
                    name,
                    mode,
                    dynamic: _,
                    meta: _,
                } => {
                    cType::ClassType(CffiFieldTypeClass {
                        name: Some(create_cffi_type_name(name, match mode {
                            baml_types::StreamingMode::NonStreaming => CffiTypeNamespace::Types,
                            baml_types::StreamingMode::Streaming => CffiTypeNamespace::StreamTypes,
                        })),

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Remove the function-typed field/parameter from the BAML schema
  2. Model the behavior as a BAML function called by name rather than a passed function value
  3. Upgrade BAML to check for added FFI support for arrow types

Example fix

// before
class C { handler fn(int) -> string }
// after
// register the function as a BAML function and call it instead of storing it in a field
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: A BAML type tree contains a function/lambda type (e.g. a class field typed as a function) being encoded for the CFFI client runtime.

Common situations: Declaring higher-order/functional types in BAML schemas; referencing generated types that embed function signatures into client bindings.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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