BoundaryML/baml · error
failed to get function name: %w
Error message
failed to get function name: %w
What it means
This error wraps any failure from raw_objects.CallMethod when FunctionName() asks the BAML runtime (via the C FFI) for the 'function_name' attribute of a FunctionLog. It is a pass-through wrapper: the real cause (failed FFI call, nil pointer, proto unmarshal failure, or object-response decode failure) is in the wrapped error. It means the Go client could not successfully retrieve this property from the runtime object.
Source
Thrown at engine/language_client_go/pkg/rawobjects_function_log.go:44
func (f *functionLog) Id() (string, error) {
result, err := raw_objects.CallMethod(f, "id", nil)
if err != nil {
return "", fmt.Errorf("failed to get ID: %w", err)
}
id, ok := result.(string)
if !ok {
return "", fmt.Errorf("unexpected type for ID: %T", result)
}
return id, nil
}
func (f *functionLog) FunctionName() (string, error) {
result, err := raw_objects.CallMethod(f, "function_name", nil)
if err != nil {
return "", fmt.Errorf("failed to get function name: %w", err)
}
name, ok := result.(string)
if !ok {
return "", fmt.Errorf("unexpected type for function name: %T", result)
}
return name, nil
}
func (f *functionLog) LogType() (string, error) {
result, err := raw_objects.CallMethod(f, "log_type", nil)
if err != nil {
return "", fmt.Errorf("failed to get log type: %w", err)
}
logType, ok := result.(string)
if !ok {View on GitHub (pinned to bd85ce9dee)
Solutions
- Read the wrapped cause via errors.Unwrap / %w output to identify whether it is 'failed to call object method function', 'object method function returned nil pointer', or a decode failure.
- Ensure you access the FunctionLog while the function call/stream it belongs to is still valid; don't cache log objects beyond the request lifetime.
- Align the Go client version with the BAML runtime (re-run `baml generate` so the client and engine match).
- If the underlying error is a decode/unmarshal failure, report it upstream with your baml CLI and client versions; it indicates an FFI contract mismatch.
Defensive patterns
Strategy: try-catch
Validate before calling
if fnLog == nil {
return errors.New("function log is nil; cannot read FunctionName")
} Type guard
func isCallMethodFailure(err error) bool {
return errors.Is(err, errCallFailed) || strings.Contains(err.Error(), "failed to call object method")
} Try / catch
name, err := fnLog.FunctionName()
if err != nil {
log.Printf("FunctionName unavailable: %v (wrapped: %v)", err, errors.Unwrap(err))
return fmt.Errorf("baml function log inaccessible: %w", err)
} Prevention
- Always log the unwrapped cause — this error is a wrapper and the root cause is beneath it.
- Access logs during the owning function call/stream lifetime.
- Regenerate the client after any BAML runtime/CLI upgrade.
- Don't share functionLog objects across goroutines or process boundaries.
When it happens
Trigger: Calling FunctionName() on a functionLog when the underlying runtime object pointer is invalid or already destroyed, the runtime returns an empty/nil buffer ('failed to call object method function'), or protobuf unmarshalling/decoding of the response fails.
Common situations: Iterating logs from a finished function stream after the runtime cleaned them up; stale collector/log references held across long-lived processes; version skew between the generated Go client and the BAML runtime library.
Related errors
- failed to get log type: %w
- failed to get timing: %w
- failed to get usage: %w
- failed to get raw LLM response: %w
- %s
AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12).
Data as JSON: /api/errors/adb315e994bd7cb0.
Report an issue: GitHub.