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

Inspect the wrapped cause via errors.Unwrap(err) to find the real failure.

failed to get name

Error message

failed to get name: %w

What it means

Collector.Name() calls the runtime's `name` method and wraps any CallMethod failure as "failed to get name: %w". The wrapper hides the real cause, which arrives as the wrapped error: an FFI-level failure, a runtime exception, or an invalid collector object. It means the collector's name could not be fetched from the runtime at all — distinct from the type-assertion error that fires when decoding succeeds but the shape is wrong.

Solutions

Inspect the wrapped cause via errors.Unwrap(err) to find the real failure.
Only call Name() on collectors created with b.Collector("name", ...); construct named collectors explicitly.
Recreate the collector if the runtime was restarted, and keep usage within a single process lifetime.
Add a retry with backoff to distinguish transient FFI failures from a persistently broken object.

Example fix

// before
name, err := collector.Name()
// after
name, err := collector.Name()
if err != nil {
    return "", fmt.Errorf("collector name unavailable: %w", err) // check wrapped cause
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Create named collectors explicitly:
// col := b.Collector("my-collector", ...); if col == nil { ... }

Type guard

func hasName(c baml.Collector) bool { return c != nil }

Try / catch

name, err := collector.Name()
if err != nil {
    if strings.Contains(err.Error(), "failed to get name") {
        return "", fmt.Errorf("collector unusable (runtime object invalid?): %w", err)
    }
    return "", err
}

Prevention

Use named collectors (b.Collector("name", ...)) when you plan to read the name back
Keep collector usage inside the runtime's process lifetime
Check errors.Unwrap(err) to diagnose the true cause
Avoid using collectors after runtime teardown

When it happens

Trigger: Calling collector.Name() on a collector whose runtime object is invalid or freed, when the runtime raises inside `name`, or when the FFI bridge itself errors before returning a result.

Common situations: Using an anonymous collector created without a name where the runtime still errors instead of returning empty; accessing a collector after runtime teardown; sharing a collector across process boundaries.

Understand the failure class

Background: "API request failed": what wrapped HTTP errors from external APIs mean and how to find the real cause — this error's family across 29 libraries.

Related errors

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

Appendix: source

Thrown at engine/language_client_go/pkg/rawobjects_collector.go:44

func (c *collector) Usage() (Usage, error) {
	result, err := raw_objects.CallMethod(c, "usage", nil)
	if err != nil {
		return nil, fmt.Errorf("failed to get usage: %w", err)
	}

	usage, ok := result.(Usage)
	if !ok {
		return nil, fmt.Errorf("unexpected type for usage: %T", result)
	}

	return usage, nil
}

func (c *collector) Name() (string, error) {
	result, err := raw_objects.CallMethod(c, "name", nil)
	if err != nil {
		return "", fmt.Errorf("failed to get name: %w", err)
	}

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

	return name, nil
}

func (c *collector) Logs() ([]FunctionLog, error) {
	result, err := raw_objects.CallMethod(c, "logs", nil)
	if err != nil {
		return nil, fmt.Errorf("failed to get logs: %w", err)
	}

	logs, ok := result.([]raw_objects.RawPointer)
	if !ok {

View on GitHub (pinned to bd85ce9dee)