apache/beam · error

empty type

Error message

empty type

What it means

decodeType converts a v1pb.Type protobuf message into a reflect.Type during coder/graph deserialization. A nil *v1pb.Type carries no type information at all, so decodeType immediately fails with this error (context-wrapped) rather than guessing a type.

Source

Thrown at sdks/go/pkg/beam/core/runtime/graphx/serialize.go:563

	case typex.VType:
		return v1pb.Type_V, true
	case typex.WType:
		return v1pb.Type_W, true
	case typex.XType:
		return v1pb.Type_X, true
	case typex.YType:
		return v1pb.Type_Y, true
	case typex.ZType:
		return v1pb.Type_Z, true

	default:
		return v1pb.Type_ILLEGAL, false
	}
}

func decodeType(t *v1pb.Type) (reflect.Type, error) {
	if t == nil {
		err := errors.New("empty type")
		return nil, errors.WithContextf(err, "decoding type %v", t)
	}

	switch t.Kind {
	case v1pb.Type_BOOL:
		return reflectx.Bool, nil
	case v1pb.Type_INT:
		return reflectx.Int, nil
	case v1pb.Type_INT8:
		return reflectx.Int8, nil
	case v1pb.Type_INT16:
		return reflectx.Int16, nil
	case v1pb.Type_INT32:
		return reflectx.Int32, nil
	case v1pb.Type_INT64:
		return reflectx.Int64, nil
	case v1pb.Type_UINT:
		return reflectx.Uint, nil

View on GitHub (pinned to 12126d8942)

Solutions

  1. Ensure the marshaling side always populates the Type field before serializing.
  2. Regenerate the serialized graph/coder with a matching Beam version.
  3. Inspect the proto payload for the nil Type and fix it at the producer.
Defensive patterns

Strategy: type-guard

Validate before calling

if t == nil { return errors.New("serialized graph contains nil Type") }

Type guard

func hasType(t *v1pb.Type) bool { return t != nil && t.Kind != v1pb.Type_ILLEGAL }

Try / catch

rt, err := decodeType(pbType)
if err != nil {
    return fmt.Errorf("coder deserialization failed: %w", err)
}

Prevention

When it happens

Trigger: Decoding a serialized graph/coder where a Type field in the protobuf is nil — e.g. decodeCustomCoder, decodeFn, decodeUserFn, or recursive decodeFullType/decodeType/decodeTypes walk hitting a missing Type submessage.

Common situations: Corrupted or truncated pipeline/coder protos; hand-built protobufs missing required Type fields; cross-version serialization bugs where a new optional type field is absent in old payloads.

Related errors


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