unknown method '{}' at {:?}, should have been caught during

Error message

unknown method '{}' at {:?}, should have been caught during typechecking

What it means

evaluate_method_call reached its catch-all arm for a method name it does not implement. The message explicitly states this should have been caught during typechecking, so it signals an internal invariant violation: the typechecker allowed a method call the interpreter does not know (a typechecker/interpreter desync).

Source

Thrown at engine/baml-compiler/src/thir/interpret.rs:3016

                    meta.0
                ),
            };

            if args.len() > 1 {
                bail!("to_fixed() method takes at most 1 argument at {:?}", meta.0);
            }

            let digits = match args.first() {
                Some(BamlValueWithMeta::Int(v, _)) => *v,
                Some(_) => bail!("to_fixed() digits argument must be an int at {:?}", meta.0),
                None => 0,
            };

            let formatted = baml_vm::native::number_to_fixed(value, digits)
                .map_err(|msg| anyhow::anyhow!("{msg} at {:?}", meta.0))?;
            Ok(BamlValueWithMeta::String(formatted, meta.clone()))
        }
        _ => bail!(
            "unknown method '{}' at {:?}, should have been caught during typechecking",
            method_name,
            meta.0
        ),
    }
}

#[cfg(test)]
mod tests {
    use std::path::PathBuf;

    #[allow(unused_imports)]
    use baml_types::ir_type::TypeIR;
    use internal_baml_ast::parse_standalone_expression;
    use internal_baml_diagnostics::{Diagnostics, SourceFile, Span};

    use super::*;
    use crate::{

View on GitHub (pinned to bd85ce9dee)

Solutions

Upgrade the BAML runtime/compiler so the method is implemented (or downgrade usage to supported methods)
Check the supported-methods list in baml-compiler and replace the call with an available equivalent
If the typechecker should have rejected it, file a bug with the BAML team including the span

Example fix

// before (method not implemented in this version)
let parts = s.split(",");
// after (upgrade, or use supported method)
// baml-cli / dependency updated, then keep s.split(",")

Defensive patterns

Strategy: fallback

Validate before calling

// check method is supported by your baml-compiler version before use

Try / catch

try { out = receiver.unknownMethod(x); } catch (e) { log("unsupported method: " + e); out = fallback; }

Prevention

Keep baml runtime and editor tooling versions in sync
Consult the supported-methods list for your version
Report typechecker/interpreter desyncs as bugs

When it happens

Trigger: Calling a method that exists in docs/another BAML version but is not implemented in this compiler build (e.g. a newly added string/array method on an older interpreter), or a typechecker bug admitting an unsupported method.

Common situations: Version skew between editor/tooling support and the installed baml runtime; trying methods from other languages (e.g. .split, .trim) before they are implemented in the interpreter.

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/1d053dbcb1c760c0. Report an issue: GitHub.