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

Align the DoFn's ProcessElement to emit exactly 6 outputs.

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

Error message

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

What it means

Panic raised by ParDo6 when MustN(TryParDo(...)) yields a slice whose length is not exactly 6. The DoFn's output arity (number of emitted outputs / output tags) disagrees with the 6 outputs this fixed-arity helper unpacks, so the tuple unpack cannot proceed; the message via formatParDoError states expected vs actual counts.

Source

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

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

// ParDo5 inserts a ParDo with 5 outputs into the pipeline.
func ParDo5(s Scope, dofn any, col PCollection, opts ...Option) (PCollection, PCollection, PCollection, PCollection, PCollection) {
	ret := MustN(TryParDo(s, dofn, col, opts...))
	if len(ret) != 5 {
		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

View on GitHub (pinned to 12126d8942)

Solutions

Align the DoFn's ProcessElement to emit exactly 6 outputs.
Or use the ParDoN variant matching the actual output count.
Switch to TryParDo/ParDoN when output count is computed at runtime.

Example fix

// before: DoFn has only 6 emit fields but one is unused/not counted
// after: ensure exactly 6 emit funcs are declared and used in ProcessElement
beam.ParDo6(s, &fn{}, col)

Defensive patterns

Strategy: validation

Validate before calling

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

Try / catch

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

Prevention

For high fan-out DoFns, name emit fields clearly to avoid miscounting
Use TryParDo when the output count is data-dependent
Keep one DoFn definition per ParDoN call site

When it happens

Trigger: Calling beam.ParDo6 with a DoFn whose ProcessElement does not emit exactly 6 outputs.

Common situations: Large fan-out DoFns are error-prone; typically a DoFn with 5 or 7 emits is passed, or emit struct fields were reordered/removed during refactoring.

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