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

  1. 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.
  2. 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.
  3. Align the Go client version with the BAML runtime (re-run `baml generate` so the client and engine match).
  4. 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

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


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