What causes "panic(formatParDoError(dofn, len(ret), 7))" in apache/beam?

Make ProcessElement emit exactly 7 outputs (7 emit fields or 7 return values).

panic(formatParDoError(dofn, len(ret), 7))

Error message

panic(formatParDoError(dofn, len(ret), 7))

What it means

Panic raised by ParDo7 when TryParDo returns a count of output PCollections different from 7. As with the other fixed-arity ParDoN wrappers, this is a construction-time arity mismatch between what the DoFn actually emits and the number of return values the caller expects to unpack.

Source

Thrown at sdks/go/pkg/beam/pardo.go:487

		panic(formatParDoError(dofn, len(ret), 5))
	}
	return ret[0], ret[1], ret[2], ret[3], ret[4]
}

// ParDo6 inserts a ParDo with 6 outputs into the pipeline.
func ParDo6(s Scope, dofn any, col PCollection, opts ...Option) (PCollection, PCollection, PCollection, PCollection, PCollection, PCollection) {
	ret := MustN(TryParDo(s, dofn, col, opts...))
	if len(ret) != 6 {
		panic(formatParDoError(dofn, len(ret), 6))
	}
	return ret[0], ret[1], ret[2], ret[3], ret[4], ret[5]
}

// ParDo7 inserts a ParDo with 7 outputs into the pipeline.
func ParDo7(s Scope, dofn any, col PCollection, opts ...Option) (PCollection, PCollection, PCollection, PCollection, PCollection, PCollection, PCollection) {
	ret := MustN(TryParDo(s, dofn, col, opts...))
	if len(ret) != 7 {
		panic(formatParDoError(dofn, len(ret), 7))
	}
	return ret[0], ret[1], ret[2], ret[3], ret[4], ret[5], ret[6]
}

// formatParDoError is a helper function to provide a more concise error
// message to the users when a DoFn and its ParDo pairing is incorrect.
//
// We construct a new graph.Fn using the doFn which is passed. We explicitly
// ignore the error since we already know that its already a DoFn type as
// TryParDo would have panicked otherwise.
func formatParDoError(doFn any, emitSize int, parDoSize int) string {
	doFun, _ := graph.NewFn(doFn)
	doFnName := doFun.Name()

	thisParDo := parDoForSize(parDoSize) // Conveniently keeps the API slim.
	correctParDo := parDoForSize(emitSize)

	return fmt.Sprintf("DoFn %v has %v outputs, but %v requires %v outputs, use %v instead.", doFnName, emitSize, thisParDo, parDoSize, correctParDo)

View on GitHub (pinned to 12126d8942)

Solutions

Make ProcessElement emit exactly 7 outputs (7 emit fields or 7 return values).
Or pick the ParDoN helper matching the DoFn's actual count.
For dynamic counts, use TryParDo and handle the error instead of panicking.

Example fix

// before: 7 emit tags declared, only 6 wired into ProcessElement
// after: wire all 7 emitters in ProcessElement
beam.ParDo7(s, &fn{}, col)

Defensive patterns

Strategy: validation

Validate before calling

if outputsOfMyDoFn != 7 { log.Fatalf("expected 7 outputs, got %d", outputsOfMyDoFn) }

Try / catch

defer func() { if r := recover(); r != nil { err = fmt.Errorf("ParDo7 failed: %v", r) } }()

Prevention

Wire every emit field into ProcessElement; unused emits change the arity
Test pipeline construction in unit tests to fail fast
Consider restructuring with fewer output tags if arity keeps drifting

When it happens

Trigger: Calling beam.ParDo7 with a DoFn whose ProcessElement does not emit exactly 7 outputs.

Common situations: Rarely used high-fan-out variant; usually hit when a team generalizes an existing multi-output DoFn or miscounts emit parameters in a large ProcessElement signature.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

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