BoundaryML/baml · error
failed to get log type: %w
Error message
failed to get log type: %w
What it means
This error wraps any failure from raw_objects.CallMethod when LogType() requests the 'log_type' attribute of a FunctionLog over the C FFI. It is a wrapper: the actionable cause (empty FFI buffer, nil pointer, proto unmarshal error, or object-response decode failure) is carried in the wrapped error. It signals the Go client could not retrieve this property from the runtime object at all.
Source
Thrown at engine/language_client_go/pkg/rawobjects_function_log.go:58
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 {
return "", fmt.Errorf("unexpected type for log type: %T", result)
}
return logType, nil
}
func (f *functionLog) Timing() (Timing, error) {
result, err := raw_objects.CallMethod(f, "timing", nil)
if err != nil {
return nil, fmt.Errorf("failed to get timing: %w", err)
}
timing, ok := result.(Timing)
if !ok {View on GitHub (pinned to bd85ce9dee)
Solutions
- Inspect the wrapped error (errors.Unwrap) to distinguish 'failed to call object method function', 'returned nil pointer', or decode failures.
- Access the log within the lifetime of its owning function call/stream; do not cache log objects past the stream end.
- Re-run `baml generate` to keep the Go client in sync with the BAML runtime version.
- Report persistent decode/unmarshal failures upstream with your client and runtime versions.
Defensive patterns
Strategy: try-catch
Validate before calling
if fnLog == nil {
return errors.New("function log is nil; cannot read LogType")
} Type guard
func isCallMethodFailure(err error) bool {
return strings.Contains(err.Error(), "failed to call object method")
} Try / catch
lt, err := fnLog.LogType()
if err != nil {
log.Printf("LogType unavailable: %v (wrapped: %v)", err, errors.Unwrap(err))
return fmt.Errorf("baml function log inaccessible: %w", err)
} Prevention
- Inspect errors.Unwrap — the root FFI cause is in the wrapped error.
- Read LogType within the stream's lifetime.
- Regenerate the client after BAML runtime upgrades.
- Avoid caching functionLog references in long-lived services.
When it happens
Trigger: Calling LogType() when the underlying function-log runtime object is stale/destroyed, the FFI method call returns an empty buffer, or the protobuf response fails to unmarshal/decode.
Common situations: Using a FunctionLog obtained from a completed stream after cleanup; holding collector logs across process boundaries; version mismatch between generated Go client and BAML runtime.
Related errors
- failed to get function name: %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/b43837addf8b946c.
Report an issue: GitHub.