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

Unwrap the wrapped error to find the native-side cause (invalid handle, method not found, etc.).

failed to get start time

Error message

failed to get start time: %w

What it means

timing.StartTimeUTCMs() calls the FFI method "start_time_utc_ms" on the underlying timing object. Errors from raw_objects.CallMethod are wrapped as "failed to get start time: %w". This signals the native BAML runtime failed to produce the start timestamp, typically because the underlying object handle is invalid or a runtime mismatch occurred.

Solutions

Unwrap the wrapped error to find the native-side cause (invalid handle, method not found, etc.).
Ensure you access Timing only while the FunctionLog/LLMCall and its runtime are still valid.
Match the baml Go module version to your BAML native runtime version.
If timing is genuinely absent, treat a failed start-time read as missing metadata and skip it rather than failing the pipeline.

Example fix

// before
startMs, err := timing.StartTimeUTCMs()
if err != nil {
    panic(err)
}

// after: tolerate missing timing metadata
startMs, err := timing.StartTimeUTCMs()
if err != nil {
    log.Printf("timing unavailable: %v", err)
    startMs = 0
}

Defensive patterns

Strategy: try-catch

Validate before calling

if timing == nil {
    return errors.New("timing object is nil")
}

Try / catch

startMs, err := timing.StartTimeUTCMs()
if err != nil {
    log.Printf("start time unavailable: %v", err)
    startMs = 0 // degrade instead of failing telemetry
}

Prevention

Read timing metadata while the FunctionLog/LLMCall runtime is still alive.
Treat timing fields as optional telemetry; never let them crash pipelines.
Match baml Go binding and native runtime versions.

When it happens

Trigger: Calling StartTimeUTCMs() (via function log / LLM call timing accessors, e.g. in collectors or test harnesses) when the underlying "start_time_utc_ms" FFI call returns an error, such as an invalid or freed raw object pointer.

Common situations: Accessing timing info on a function log after the runtime was released; mismatched Go binding / native runtime versions; timing object not populated because the call failed before timing was recorded.

Related errors

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

Appendix: source

Thrown at engine/language_client_go/pkg/rawobjects_timing.go:30

	*raw_objects.RawObject
}

func newTiming(ptr int64, rt unsafe.Pointer) Timing {
	return &timing{raw_objects.FromPointer(ptr, rt)}
}

func (t *timing) ObjectType() cffi.BamlObjectType {
	return cffi.BamlObjectType_OBJECT_TIMING
}

func (t *timing) pointer() int64 {
	return t.RawObject.Pointer()
}

func (t *timing) StartTimeUTCMs() (int64, error) {
	result, err := raw_objects.CallMethod(t, "start_time_utc_ms", nil)
	if err != nil {
		return 0, fmt.Errorf("failed to get start time: %w", err)
	}

	startTime, ok := result.(int64)
	if !ok {
		return 0, fmt.Errorf("unexpected type for start time: %T", result)
	}

	return startTime, nil
}

func (t *timing) DurationMs() (*int64, error) {
	result, err := raw_objects.CallMethod(t, "duration_ms", nil)
	if err != nil {
		return nil, fmt.Errorf("failed to get duration: %w", err)
	}

	if result == nil {
		return nil, nil

View on GitHub (pinned to bd85ce9dee)