apache/beam · error

element type mismatch, previous additions were of type

Error message

element type mismatch, previous additions were of type %v, tried to add type %v

What it means

A TestStream PCollection must have a single element type, so the first AddElements call fixes the config's element type. AddElements rejects any subsequent call whose first element's reflect.Type differs from the recorded type.

Solutions

  1. Use a separate TestStream config for each element type
  2. Make all AddElements calls use the same concrete type (e.g. consistently int64)
  3. Convert elements to a common type before adding
  4. Verify element types match what the pipeline's beam.Create/TestStream expects

Example fix

// before
cfg.AddElements(0, 1, 2)      // int
cfg.AddElements(10, "three")  // mismatch
// after
cfg.AddElements(0, int64(1), int64(2))
cfg.AddElements(10, int64(3))
Defensive patterns

Strategy: type-guard

Validate before calling

if firstType == nil { firstType = reflect.TypeOf(elements[0]) } else if reflect.TypeOf(elements[0]) != firstType { /* handle mismatch */ }

Type guard

func sameType(prev reflect.Type, elems ...any) bool {
    if len(elems) == 0 { return true }
    return prev == reflect.TypeOf(elems[0])
}

Try / catch

if err := cfg.AddElements(ts, elems...); err != nil {
    t.Fatalf("element type mismatch: %v", err)
}

Prevention

When it happens

Trigger: Calling Config.AddElements twice with elements of different Go types (e.g. first []any{1,2} (int) then string elements) on the same TestStream config.

Common situations: Reusing one TestStream config for multiple PCollections of different types, or passing untyped literals that resolve to different concrete types (int vs int64).

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


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

Appendix: source

Thrown at sdks/go/pkg/beam/testing/teststream/teststream.go:117

// AdvanceProcessingTimeToInfinity moves the TestStream processing time to the largest possible
// timestamp.
func (c *Config) AdvanceProcessingTimeToInfinity() {
	c.AdvanceProcessingTime(mtime.MaxTimestamp.Milliseconds())
}

// AddElements adds a number of elements to the stream at the specified event timestamp. Must be called with
// at least one element.
//
// On the first call, a type will be inferred from the passed in elements, which must be of all the same type.
// Type mismatches on this or subsequent calls will cause AddElements to return an error.
//
// Element types must have built-in coders in Beam.
func (c *Config) AddElements(timestamp int64, elements ...any) error {
	t := reflect.TypeOf(elements[0])
	if c.elmType == nil {
		c.elmType = typex.New(t)
	} else if c.elmType.Type() != t {
		return fmt.Errorf("element type mismatch, previous additions were of type %v, tried to add type %v", c.elmType, t)
	}
	for i, ele := range elements {
		if reflect.TypeOf(ele) != c.elmType.Type() {
			return fmt.Errorf("element %d was type %T, previous additions were of type %v", i, ele, c.elmType)
		}
	}
	newElements := []*pipepb.TestStreamPayload_TimestampedElement{}
	enc := beam.NewElementEncoder(t)
	for _, e := range elements {
		var buf bytes.Buffer
		if err := enc.Encode(e, &buf); err != nil {
			return fmt.Errorf("encoding value %v failed, got %v", e, err)
		}
		newElements = append(newElements, &pipepb.TestStreamPayload_TimestampedElement{EncodedElement: buf.Bytes(), Timestamp: timestamp})
	}
	addElementsEvent := &pipepb.TestStreamPayload_Event_AddElements{Elements: newElements}
	elementEvent := &pipepb.TestStreamPayload_Event_ElementEvent{ElementEvent: addElementsEvent}
	c.events = append(c.events, &pipepb.TestStreamPayload_Event{Event: elementEvent})

View on GitHub (pinned to 12126d8942)