apache/beam · error

inferCoder: unknown container kind %v

Error message

inferCoder: unknown container kind %v

What it means

Inside beam's inferCoder, container FullTypes are dispatched by kind (CoGBK, Windowed, etc.). If a container kind is not one of the handled cases, the code panics with 'inferCoder: unknown container kind %v', naming the unrecognized type. This indicates the type falls outside the SDK's supported coding schemes.

Source

Thrown at sdks/go/pkg/beam/coder.go:184

}

func inferCoder(t FullType) (*coder.Coder, error) {
	switch t.Class() {
	case typex.Container:
		switch t.Type() {
		case reflectx.ByteSlice:
			return &coder.Coder{Kind: coder.Bytes, T: t}, nil
		}
		switch t.Type().Kind() {
		case reflect.Slice:
			c, err := inferCoder(t.Components()[0])
			if err != nil {
				return nil, err
			}
			return &coder.Coder{Kind: coder.Iterable, T: t, Components: []*coder.Coder{c}}, nil

		default:
			panic(fmt.Sprintf("inferCoder: unknown container kind %v", t))
		}
	case typex.Concrete:
		switch t.Type() {
		case reflectx.Int64:
			// use the beam varint coder.
			return &coder.Coder{Kind: coder.VarInt, T: t}, nil
		case reflectx.Int, reflectx.Int8, reflectx.Int16, reflectx.Int32:
			c, err := coderx.NewVarIntZ(t.Type())
			if err != nil {
				return nil, err
			}
			return coder.CoderFrom(c), nil
		case reflectx.Uint, reflectx.Uint8, reflectx.Uint16, reflectx.Uint32, reflectx.Uint64:
			c, err := coderx.NewVarUintZ(t.Type())
			if err != nil {
				return nil, err
			}
			return coder.CoderFrom(c), nil

View on GitHub (pinned to 12126d8942)

Solutions

1. Upgrade the Apache Beam Go SDK to a version that supports the container kind in question
2. Avoid manually constructing unusual typex container types; use standard builders (typex.New, CoGBK, Windowed wrappers)
3. Register a custom coder for the element type and construct the coder explicitly instead of relying on inference
4. Check for SDK version mismatch between pipeline submitter and runner

Example fix

// before
c := beam.NewCoder(customContainerType) // panics in default branch
// after
// construct coder explicitly with known kind:
c := beam.Coder{Coder: &coder.Coder{Kind: coder.Iterable, T: t, Components: []*coder.Coder{elemCoder}}}

switch t.Class() {
case typex.Container:
	// verify kind is one handled: CoGBK, Windowed, etc. before calling NewCoder
}

func safeInfer(t typex.FullType) (c *coder.Coder, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("unsupported container kind %v", t)
		}
	}()
	// invoke inference path
	return nil, nil
}

When it happens

Trigger: Inferring coders for a container FullType with an unhandled kind — typically new/odd typex container kinds introduced by other SDK versions, custom typex constructions, or nested unsupported containers.

Common situations: Cross-language or cross-version pipelines where the type graph includes container kinds this Go SDK version doesn't know; manually constructing typex container types not produced by standard builders.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Unexpected composite type: %v
• Unexpected type: %v
• Invalid Coder
• err
• coder must not be nil

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