What causes "failed to get provider: %w" in BoundaryML/baml?

Read provider within the same scope/callback where the LLMCall is produced, before runtime cleanup.

failed to get provider: %w

Error message

failed to get provider: %w

What it means

LLMCall.Provider() wraps any error from the FFI CallMethod(l, "provider", nil) used to read the provider name (e.g. OpenAI, Anthropic) of an LLM call. It means the BAML runtime failed to resolve or return the "provider" attribute on this call object. This is a binding-level failure — the call object handle or the attribute dispatch across the Go/Rust boundary did not work.

Source

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

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 {
		return "", fmt.Errorf("unexpected type for provider: %T", result)
	}

	return provider, nil
}

func (l *llmCall) HttpRequest() (HTTPRequest, error) {
	result, err := raw_objects.CallMethod(l, "http_request", nil)
	if err != nil {
		return nil, fmt.Errorf("failed to get http request: %w", err)
	}

	request, ok := result.(HTTPRequest)
	if !ok {

View on GitHub (pinned to bd85ce9dee)

Solutions

Read provider within the same scope/callback where the LLMCall is produced, before runtime cleanup.
Update the BAML Go bindings and native runtime to matching versions and regenerate.
Unwrap the error (errors.Unwrap) to see the specific FFI failure reason.
Use the trace/event metadata for provider info when post-call access fails.

Example fix

// before: deferred access to a stored call
provider, err := storedCall.Provider()

// after: access inside the callback
onEvent := func(ev baml.Event) {
    provider, err := ev.Call().Provider()
    if err != nil {
        log.Printf("provider unavailable: %v", err)
    }
}

Defensive patterns

Strategy: try-catch

Validate before calling

if call == nil || reflect.ValueOf(call).IsNil() {
    return errors.New("llm call object is nil/stale; cannot read provider")
}

Try / catch

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

Prevention

Read provider attributes while the call object is still live.
Match runtime and binding versions.
Do not hold call objects beyond function completion.
Unwrap chained errors for root-cause diagnosis.

When it happens

Trigger: Calling Provider() on an llmCall whose RawObject pointer is stale or freed on the Rust side, or when the runtime errors while dispatching the "provider" method on the object.

Common situations: Accessing the LLMCall after the runtime released its objects (e.g. storing it past the end of a streamed function call); version skew between the Go bindings and native runtime removing/renaming "provider"; cross-thread access to runtime-owned objects.

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