emit parameter in method %v does not match emit parameter in

Error message

emit parameter in method %v does not match emit parameter in %v

What it means

When a DoFn auxiliary method's emit parameters match ProcessElement's emit count, validateEmits also checks each emit parameter's type. If the i-th emit type in the method differs from the i-th emit type in ProcessElement, a funcx.TypeMismatchError is wrapped with this message and thrown from AsDoFn during graph construction.

Source

Thrown at sdks/go/pkg/beam/core/graph/fn.go:726

			methodName, processElementName, methodName)
	}

	// Error if number of emits doesn't match.
	if numMethodEmits != numProcessEmits {
		err := errors.Errorf("number of emits in method %v does not match method %v: got %d, expected %d",
			methodName, processElementName, numMethodEmits, numProcessEmits)
		return errors.SetTopLevelMsgf(err,
			"Incorrect number of emit parameters in the %v method of a DoFn. "+
				"The emit parameters should match those of the %v method.",
			methodName, processElementName)
	}

	// Error if there's a type mismatch.
	methodEmits := method.Param[posMethodEmits : posMethodEmits+numMethodEmits]
	for i := 0; i < numProcessEmits; i++ {
		if processFnEmits[i].T != methodEmits[i].T {
			var err error = &funcx.TypeMismatchError{Got: methodEmits[i].T, Want: processFnEmits[i].T}
			err = errors.Wrapf(err, "emit parameter in method %v does not match emit parameter in %v",
				methodName, processElementName)
			return errors.SetTopLevelMsgf(err,
				"Incorrect emit parameters in the %v method of a DoFn. "+
					"The emit parameters should match those of the %v method.",
				methodName, processElementName)
		}
	}

	return nil
}

// validateSideInputs compares the inputs found in a DoFn method signature with the inputs found
// in the signature for ProcessElement, and performs validation to check that the side inputs
// match. This function should only be used to validate methods that are expected to have matching
// side inputs to ProcessElement.
func validateSideInputs(processFnInputs []funcx.FnParam, method *funcx.Fn, methodName string, numMainIn mainInputs) error {
	if numMainIn == MainUnknown {
		return validateSideInputsNumUnknown(processFnInputs, method, methodName)

View on GitHub (pinned to 12126d8942)

Solutions

Change the auxiliary method's emit parameter types to exactly match the corresponding ProcessElement emit types in order.
Verify order matters: the i-th emit in the auxiliary method must match the i-th emit in ProcessElement.
Use identical emitter function types (copy the signature from ProcessElement).

Example fix

// before
func (fn *myFn) ProcessElement(w string, emit func(int)) {}
func (fn *myFn) StartBundle(emit func(string)) {}

// after
func (fn *myFn) ProcessElement(w string, emit func(int)) {}
func (fn *myFn) StartBundle(emit func(int)) {}

Defensive patterns

Strategy: validation

Validate before calling

// ensure emitter types are declared once and reused:
type emitFn = func(int)
// ProcessElement(w string, emit emitFn) and auxiliary methods use emitFn too

Type guard

func sameEmitType(a, b reflect.Type) bool { return a == b }

Try / catch

defer func() { if r := recover(); r != nil { log.Fatalf("emit type mismatch: %v", r) } }()
// or check returned error from pipeline build:
if err := p.Run(); err != nil { /* signature errors surface here */ }

Prevention

Define emitter signatures as named types and reuse them in every method
When changing an output type, grep the DoFn for all emit parameters and update all
Keep emit parameter order identical to ProcessElement in auxiliary methods

When it happens

Trigger: Declaring e.g. ProcessElement with emit func(int) but FinishBundle with emit func(string) (or an emit wrapped differently, like func(beam.X) vs func(int)), then converting the DoFn via AsDoFn / beam.ParDo.

Common situations: Changing an output element type in ProcessElement without updating auxiliary methods; using similar-looking emitter signatures on different element types; generics or custom emitter types that don't match the ProcessElement emitters exactly.

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/293fa2dcc17f1266. Report an issue: GitHub.