Failed to optimize AddInput for combiner %v. Failed to infer

Error message

Failed to optimize AddInput for combiner %v. Failed to infer types

What it means

This panic comes from Apache Beam Go SDK's generated combiner registration code (register.tmpl). When a combiner's accumulator type exposes an AddInput method, the generator tries to specialize a fast, type-safe wrapper for it; if it cannot infer the accumulator/input types from known signatures (e.g. AddInput1x1, AddInput2x1, etc.), it panics instead of silently falling back. It signals that the user's combiner type does not match any registered template instantiation.

Source

Thrown at sdks/go/pkg/beam/register/register.tmpl:442

				return fn.(addInput2x2[T0, T2]).AddInput(a0, a1)
			})
		}
    } else if _, ok := accum.(addInput2x1[T0, T2]); ok {
        caller := func(fn any) reflectx.Func {
            f := fn.(func(T0, T2) T0)
            return &caller2x1[T0, T2, T0]{fn: f}
        }
		reflectx.RegisterFunc(reflect.TypeOf((*func(T0, T2) T0)(nil)).Elem(), caller)

        addInputWrapper = func(fn any) reflectx.Func {
			return reflectx.MakeFunc(func(a0 T0, a1 T2) T0 {
				return fn.(addInput2x1[T0, T2]).AddInput(a0, a1)
			})
		}
    } {{end}}

    if m := accumVal.MethodByName("AddInput"); m.IsValid() && addInputWrapper == nil {
        panic(fmt.Sprintf("Failed to optimize AddInput for combiner %v. Failed to infer types", accum))
    }

    var extractOutputWrapper func(fn any) reflectx.Func
    if _, ok := accum.(extractOutput1x2[T0, T0]); ok {
        caller := func(fn any) reflectx.Func {
            f := fn.(func(T0) (T0, error))
            return &caller1x2[T0, T0, error]{fn: f}
        }
		reflectx.RegisterFunc(reflect.TypeOf((*func(T0) (T0, error))(nil)).Elem(), caller)

        extractOutputWrapper = func(fn any) reflectx.Func {
			return reflectx.MakeFunc(func(a0 T0) (T0, error) {
				return fn.(extractOutput1x2[T0, T0]).ExtractOutput(a0)
			})
		}
    } else if _, ok := accum.(extractOutput1x1[T0, T0]); ok {
        caller := func(fn any) reflectx.Func {
            f := fn.(func(T0) T0)

View on GitHub (pinned to 12126d8942)

Solutions

Change the accumulator's AddInput method signature to one of the supported generated arities/types (e.g. AddInput(T0) or AddInput(T0, T1) with registered types).
Remove the explicit AddInput method from the accumulator so the SDK uses the generic reflection path instead of panicking.
Use the provided combiner helpers (beam.CombineWithContext with perf.CombineFn pattern) so the SDK infers types via RegisterDoFn/RegisterCombiner.
Ensure all custom types in the signature are registered with register.Function/Type so template inference succeeds.

Example fix

// before
type avgAcc struct{ sum int64; n int }
func (a *avgAcc) AddInput(v ...int64) { ... } // unsupported variadic

// after
type avgAcc struct{ sum int64; n int }
func (a *avgAcc) AddInput(v int64) { a.sum += v; a.n++ }

Defensive patterns

Strategy: validation

Validate before calling

// Before registering the combiner, check the AddInput method matches a supported arity
m := reflect.ValueOf(myAcc{}).MethodByName("AddInput")
if m.IsValid() {
    t := m.Type()
    if t.NumIn() > 2 || t.IsVariadic() {
        panic("AddInput signature not supported by beam codegen; reduce arity / remove variadic")
    }
}

Type guard

func hasSupportedAddInput(acc any) bool {
    m := reflect.ValueOf(acc).MethodByName("AddInput")
    if !m.IsValid() { return true }
    t := m.Type()
    return !t.IsVariadic() && t.NumIn() <= 2
}

Try / catch

// Go panics cannot be caught per-call site idiomatically in library use;
// validate at startup:
func init() {
    if !hasSupportedAddInput(myAcc{}) {
        panic("combiner AddInput signature unsupported; fix before running pipeline")
    }
}

Prevention

Keep AddInput to 1 or 2 typed parameters with no variadics.
Register all custom types with register.Type/register.Function.
Avoid renaming or reshaping accumulator methods when upgrading Beam.
Run a small unit pipeline that registers the combiner before production runs.

When it happens

Trigger: Registering a combiner via beam.Combine with an accumulator type that has an AddInput method whose signature does not match any generated wrapper variant, so the generated specialization loop leaves addInputWrapper nil while accumVal.MethodByName("AddInput") is valid.

Common situations: Defining a custom combiner with a hand-written AddInput method using unsupported types or arity (e.g. three inputs, custom structs, variadic args), or changing a combiner's accumulator type after upgrading Beam so it no longer matches generated variants.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

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