apache/beam · error

Unexpected type kind

Error message

Unexpected type kind: %v

What it means

isConcrete validates that a reflect.Type of a given class has a supported kind; kinds outside Bool, Integer, Float, Byte and String hit this panic. It is an internal completeness guard over Go's reflect.Kind space, reached only when the SDK encounters a kind it does not know how to classify as concrete.

Solutions

  1. Check the reflect.Kind of the type you pass; use only concrete encodable kinds (bool, ints, uints, floats, string, byte, slices of these).
  2. Wrap complex types with beam.Encoder/beam.Decoder registrations instead of relying on default concreteness.
  3. Use KV, slices, or primitives for PCollection elements rather than raw struct/map/func types.

Example fix

// before
var t = reflect.TypeOf(map[string]int{})
typex.CheckConcrete(typex.Composite, t, nil) // panics on map kind
// after
var t = reflect.TypeOf([]int{})
typex.CheckConcrete(typex.Container, t, nil)
Defensive patterns

Strategy: validation

Validate before calling

k := t.Kind()
switch k {
case reflect.Bool, reflect.Int, reflect.Int8, ..., reflect.String:
	// ok
default:
	return fmt.Errorf("unsupported kind for concrete type: %v", k)
}

Type guard

func isSupportedKind(t reflect.Type) bool {
	switch t.Kind() {
	case reflect.Bool, reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64,
		reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64,
		reflect.Float32, reflect.Float64, reflect.String:
		return true
	}
	return false
}

Try / catch

defer func() {
	if r := recover(); r != nil {
		log.Printf("unsupported kind %v: %v", t.Kind(), r)
	}
}()

Prevention

When it happens

Trigger: Calling typex.IsConcrete/CheckConcrete (or building a FullType) with a type whose underlying kind is not one of the handled kinds, e.g. a struct, map, func, or pointer type passed where a concrete data type is expected.

Common situations: Passing struct or map types directly as pipeline data where KV/slices/primitives are expected; custom type wrappers around unsupported kinds; SDK gaps for newer Go kinds.

Related errors


AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/f96ca8108255e860. Report an issue: GitHub.

Appendix: source

Thrown at sdks/go/pkg/beam/core/typex/class.go:197

		return nil

	case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
		return nil

	case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64:
		return nil

	case reflect.Float32, reflect.Float64:
		return nil

	case reflect.Complex64, reflect.Complex128:
		return nil

	case reflect.String:
		return nil

	default:
		panic(fmt.Sprintf("Unexpected type kind: %v", t))
	}
}

// IsContainer returns true iff the given type is an container data type,
// such as []int or []T.
func IsContainer(t reflect.Type) bool {
	// TODO(lostluck) 2019.02.03: Should we consider maps a container for
	// beam specific purposes?
	switch {
	case IsList(t):
		if IsUniversal(t.Elem()) || IsConcrete(t.Elem()) {
			return true
		}
		return IsContainer(t.Elem())
	default:
		return false
	}
}

View on GitHub (pinned to 12126d8942)