BoundaryML/baml · error · BridgeError

type arguments are not supported when invoking a BAML functi

Error message

type arguments are not supported when invoking a BAML function handle

What it means

BridgeError::FunctionHandleTypeArgs. When invoking an already-resolved BAML function handle, supplying type arguments is not supported because the handle is bound to a concrete function signature. The bridge rejects type arguments to avoid ambiguity about which instantiation to run.

Source

Thrown at baml_language/crates/bridge_cffi/src/error.rs:25

pub enum BridgeError {
    #[error(transparent)]
    Ctypes(#[from] bridge_ctypes::CtypesError),
    #[error("Engine not initialized. Call create_baml_runtime first.")]
    NotInitialized,

    #[error("Project not initialized")]
    ProjectNotInitialized,

    #[error("Engine lock poisoned")]
    LockPoisoned,

    #[error("{0}")]
    Runtime(#[from] bex_project::RuntimeError),

    #[error("CallFunctionArgs.call_target must be set")]
    MissingCallTarget,

    #[error("type arguments are not supported when invoking a BAML function handle")]
    FunctionHandleTypeArgs,

    #[error("Function not found: {name}")]
    FunctionNotFound { name: String },

    #[error("Missing argument '{parameter}' for function '{function}'")]
    MissingArgument { function: String, parameter: String },

    #[error("Not implemented: {0}")]
    NotImplemented(String),

    #[error("call_id {0} is already in use by an active call")]
    DuplicateCallId(u64),

    #[error("call_id must be a nonzero uint64")]
    InvalidCallId,

    #[error("Internal error: {0}")]

View on GitHub (pinned to bd85ce9dee)

Solutions

Remove type arguments from the handle-based invocation and call the handle directly.
Resolve the desired typed function into a concrete handle instead of parameterizing at call time.
If type selection matters, look up the specific function variant by name as call_target.

Example fix

// before
invoke(handle, type_args = ["MyOutputType"], args);
// after
invoke(handle, args);

Defensive patterns

Strategy: validation

Validate before calling

if getattr(args, 'type_args', None):
    raise ValueError('type args are not supported for function handles')

Type guard

def type_args_empty(args) -> bool:
    return not getattr(args, 'type_args', None)

Try / catch

try:
    invoke(handle, args)
except BridgeError as e:
    if 'type arguments are not supported' in str(e):
        invoke(handle, strip_type_args(args))

Prevention

Never pass type arguments through handle-based invocations
Resolve concrete functions by name instead of parameterizing handles

When it happens

Trigger: Calling a BAML function through a function handle while passing type arguments (generics/type parameters) in the invocation args.

Common situations: Porting generic-language call sites (TypeScript generics, Python type hints) to the FFI boundary and passing type args along; copying an invocation pattern from direct function calls, which may accept type args, to handle-based calls.

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/598c402bcbc41cf5. Report an issue: GitHub.