BoundaryML/baml · error

failed to get client name: %w

Error message

failed to get client name: %w

What it means

LLMCall.ClientName() wraps any error returned by the underlying FFI CallMethod(l, "client_name", nil) when reading the client name of an LLM call from the BAML runtime. It means the runtime could not resolve or return the "client_name" attribute for this call object — typically because the object handle is invalid, already freed, or the internal method call across the Go/Rust boundary failed. This is a low-level binding failure, not a client-configuration problem in your BAML code.

Source

Thrown at engine/language_client_go/pkg/rawobjects_llm_call.go:39

}

func (l *llmCall) pointer() int64 {
	return l.RawObject.Pointer()
}

func (l *llmCall) RequestId() (string, error) {
	result, err := raw_objects.CallMethod(l, "http_request_id", nil)
	if err != nil {
		return "", fmt.Errorf("failed to get request id: %w", err)
	}

	return result.(string), nil
}

func (l *llmCall) ClientName() (string, error) {
	result, err := raw_objects.CallMethod(l, "client_name", nil)
	if err != nil {
		return "", fmt.Errorf("failed to get client name: %w", err)
	}

	name, ok := result.(string)
	if !ok {
		return "", fmt.Errorf("unexpected type for client name: %T", result)
	}

	return name, nil
}

func (l *llmCall) Provider() (string, error) {
	result, err := raw_objects.CallMethod(l, "provider", nil)
	if err != nil {
		return "", fmt.Errorf("failed to get provider: %w", err)
	}

	provider, ok := result.(string)
	if !ok {

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Read client_name within the callback/function-call scope where the LLMCall was delivered, before the runtime can clean it up.
2. Regenerate/upgrade the BAML Go bindings so the Go client and native runtime versions match (baml-cli generate / go get -u github.com/boundaryml/baml).
3. Inspect the wrapped error (%w) with errors.Unwrap to see the underlying FFI reason before retrying.
4. If you only need the client name for logging, prefer the FunctionLLMCall event/trace payload instead of probing the raw object after the fact.

Example fix

// before: keeping the call object beyond the callback
var cached baml.LLMCall
onEvent := func(ev baml.Event) { cached = ev.Call() }
...
name, err := cached.ClientName() // failed to get client name

// after: consume attributes inside the event scope
onEvent := func(ev baml.Event) {
    name, err := ev.Call().ClientName()
    if err != nil {
        log.Printf("client name unavailable: %v", err)
        return
    }
    log.Printf("client=%s", name)
}

// No pre-call validation possible; ensure the runtime is alive and versions match before use.
if bamlRuntimeVersion != goBindingVersion {
    log.Fatal("BAML Go bindings and native runtime version mismatch")
}

name, err := call.ClientName()
if err != nil {
    log.Printf("client name unavailable: %v", err)
    name = "unknown"
}

When it happens

Trigger: Calling ClientName() on an llmCall whose RawObject pointer no longer resolves (e.g. the object was garbage-collected/freed on the Rust side), or when CallMethod cannot dispatch "client_name" on the object type, or the runtime returns an error for the attribute lookup.

Common situations: Holding an LLMCall reference from a function stream/callback after the BAML runtime finished and cleaned up its objects; version mismatch between the Go bindings and the native BAML runtime where the "client_name" method is missing; accessing the call from a different goroutine/thread than the runtime expects.

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

• failed to get provider: %w
• failed to get http request: %w
• failed to get http response: %w
• failed to get usage: %w
• unexpected type for client name: %T

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