BoundaryML/baml · error

error decoding value, unknown field type:

Error message

error decoding value, unknown field type: 

What it means

This is the fallthrough at the end of convertFieldTypeToGoType: the decoder received a CFFIFieldTypeHolder whose variant is not any type it knows how to map to Go. Because the Go runtime and the Rust engine were compiled against different cffi enum definitions (or a nil type was passed), no branch matches and the library panics instead of returning a wrong type.

Source

Thrown at engine/language_client_go/baml_go/serde/decode.go:476

		goType, ok := typeMap.typeMap[namespace+"."+name]
		if !ok {
			panic("error decoding value, type alias not found: " + namespace + "." + name)
		}
		return goType
	}

	// any is weird in go, (alias for interface{})
	if _, ok := type_.(*cffi.CFFIFieldTypeHolder_NullType); ok {
		if _, ok := typeMap.typeMap["INTERNAL.nil"]; ok {
			return reflect.TypeOf((*interface{})(nil)).Elem()
		}
		return reflect.TypeOf((*interface{})(nil))
	}
	if _, ok := type_.(*cffi.CFFIFieldTypeHolder_AnyType); ok {
		return reflect.TypeOf((*interface{})(nil)).Elem()
	}

	panic("error decoding value, unknown field type: " + fmt.Sprintf("%+v", fieldType))
}

func typeToString(fieldType *cffi.CFFIFieldTypeHolder) string {
	if fieldType == nil {
		panic("error decoding value")
	}

	if _, ok := fieldType.Type.(*cffi.CFFIFieldTypeHolder_StringType); ok {
		return "string"
	}
	if _, ok := fieldType.Type.(*cffi.CFFIFieldTypeHolder_BoolType); ok {
		return "bool"
	}
	if _, ok := fieldType.Type.(*cffi.CFFIFieldTypeHolder_IntType); ok {
		return "int"
	}
	if _, ok := fieldType.Type.(*cffi.CFFIFieldTypeHolder_FloatType); ok {
		return "float"

View on GitHub (pinned to bd85ce9dee)

Solutions

1. Upgrade or align the Go baml runtime and the generated client with the engine version (go get -u github.com/boundaryml/baml/... and regenerate)
2. Ensure the native baml library loaded at runtime matches the CLI version (clear stale caches, reinstall via the official installer)
3. Check the panic message's dumped fieldType (%+v) to identify the unknown variant, then upgrade to a Go client version that supports it
4. If it comes from a nested list/map/union element, isolate which BAML output type triggers it and simplify or pin versions until supported

Example fix

// before: go.mod pins old baml while native CLI is new
require github.com/boundaryml/baml v0.65.0

// after: align versions and regenerate
require github.com/boundaryml/baml v0.75.0
// baml-cli generate && go mod tidy && go build

// Startup self-check: pin and log versions
func checkVersions() {
	log.Printf("baml go runtime: %s, engine: %s", baml_go.Version, baml.EngineVersion())
	if baml_go.Version != baml.EngineVersion() {
		log.Printf("WARNING: engine/runtime version mismatch — regenerate client")
	}
}

// Decode panics are not recoverable errors; recover at the RPC boundary
func safeCall(fn func()) (recovered any) {
	defer func() { recovered = recover() }()
	fn()
	return nil
}
// usage: if r := safeCall(func(){ baml.MyFn(ctx, client, in) }); r != nil { log.Fatalf("baml decode panic: %v", r) }

When it happens

Trigger: The Rust baml engine (native lib) sends a field type variant unknown to the compiled Go runtime — e.g. using a newer engine/native lib with an older generated Go package — or a nil/invalid type descriptor reaches the converter through decodeListValue, decodeMapValue, or decodeUnionValue.

Common situations: Mixing baml versions: the native library updated by a package manager or build cache while the generated Go client was not; corrupted or hand-crafted cffi payloads in tests; engine features (new type variants) not yet supported by the installed Go client version.

Related errors

• error decoding value:
• error decoding type, checked type not found:
• error decoding value, type alias not found:
• error decoding value, unknown literal type:
• ObjectValue is not yet supported:

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