What causes "wanted one key value, got %v" in apache/beam?

Ensure the multimap function type has exactly one input parameter (the key).

wanted one key value, got

Error message

wanted one key value, got %v

What it means

multiMapValue.invoke is the reflect-made function backing a multimap side input; user code calls it with the key to obtain a keyed iterable. It expects exactly one argument (the key). If reflection hands it any other number of arguments it panics with 'wanted one key value, got ...'. This indicates a mismatch between the declared multimap function type and how it is being invoked.

Solutions

Ensure the multimap function type has exactly one input parameter (the key).
Fix the DoFn signature so the side input parameter matches beam's multimap convention.
Check that graph serialization/execution use the same SDK version so types are decoded consistently.

Example fix

// before
func (fn *f) ProcessElement(k string, v int, iter func(*int) bool) // wrong arity at call site
// after
func (fn *f) ProcessElement(k string, iter func(*int) bool) // exactly one key arg for the multimap fn

Defensive patterns

Strategy: validation

Validate before calling

// Confirm the multimap function type takes exactly one key argument:
if fnType.Kind() == reflect.Func && fnType.NumIn() != 1 {
	return fmt.Errorf("multimap fn must take exactly 1 key arg, has %d", fnType.NumIn())
}

Prevention

Use the standard DoFn multimap signature: func(key K, iter func(*V) bool).
Keep graph-producer and runner SDK versions aligned.
Avoid hand-written reflect types for side inputs in tests.
Check DoFn parameter order and arity during code review.

When it happens

Trigger: The multimap value's reflect function type (v.t) does not take exactly one input parameter, so user-code invocation or plan wiring calls it with 0 or 2+ arguments — typically caused by an illegal multimap type that slipped past UnfoldMultiMap or a mismatched DoFn signature.

Common situations: DoFn signature where the side-input parameter is a multi-argument function; incompatible SDK versions between graph construction and execution; hand-built reflection types for testing.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

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

Appendix: source

Thrown at sdks/go/pkg/beam/core/runtime/exec/input.go:235

	mm.fn = reflect.MakeFunc(t, mm.invoke).Interface()
	return mm
}

func (v *multiMapValue) Init() error {
	return nil
}

func (v *multiMapValue) Value() any {
	return v.fn
}

func (v *multiMapValue) Reset() error {
	return nil
}

func (v *multiMapValue) invoke(args []reflect.Value) []reflect.Value {
	if len(args) != 1 {
		panic(fmt.Sprintf("wanted one key value, got %v", args))
	}
	rs, err := v.adapter.NewKeyedIterable(v.ctx, v.reader, v.w, args[0].Interface())
	if err != nil {
		panic(fmt.Sprintf("failed to create keyed iterable, got %v", err))
	}
	iter := makeIter(v.t.Out(0), rs)
	iter.Init()
	return []reflect.Value{reflect.ValueOf(iter.Value())}
}

View on GitHub (pinned to 12126d8942)