What causes "passert.Count(%v) = %v, want %v" in apache/beam?

Use the message to identify which key observed which count vs expected; trace the upstream counting transforms.

passert.Count(%v) = %v, want %v

Error message

passert.Count(%v) = %v, want %v

What it means

passert.Count asserts that a PCollection of key/count pairs matches expected counts. errFn.ProcessElement fails with 'passert.Count(%v) = %v, want %v' when the observed count for a name differs from the expected count supplied to the assertion.

Source

Thrown at sdks/go/pkg/beam/testing/passert/count.go:67

	return a + 1
}

func (f *elmCountCombineFn) MergeAccumulators(a, b int) int {
	return a + b
}

func (f *elmCountCombineFn) ExtractOutput(a int) int {
	return a
}

type errFn struct {
	Name  string `json:"name,omitempty"`
	Count int    `json:"count,omitempty"`
}

func (f *errFn) ProcessElement(count int) error {
	if f.Count != count {
		return errors.Errorf("passert.Count(%v) = %v, want %v", f.Name, count, f.Count)
	}
	return nil
}

View on GitHub (pinned to 12126d8942)

Solutions

Use the message to identify which key observed which count vs expected; trace the upstream counting transforms.
Update expected counts if the new behavior is intentional.
Fix filtering/deduplication/windowing logic if counts are genuinely wrong.
Make test input deterministic.

Example fix

// before
passert.Count(s, "counts", col, map[string]int{"a": 3, "b": 2}) // pipeline yields a=4
// after
passert.Count(s, "counts", col, map[string]int{"a": 4, "b": 2}) // or fix upstream logic

Defensive patterns

Strategy: try-catch

Validate before calling

got := map[string]int{}
// collect counts from a test-side sink before asserting
if diff := cmp.Diff(want, got); diff != "" {
	t.Fatalf("count mismatch before passert: %v", diff)
}

Try / catch

if err := beamx.Execute(ctx, p); err != nil {
	if strings.Contains(err.Error(), "passert.Count") {
		// parse observed vs want from the message and diff upstream logic
	}
	t.Fatal(err)
}

Prevention

Keep test input deterministic.
Re-derive expected counts whenever aggregation logic changes.
Log intermediate PCollections during test debugging.

When it happens

Trigger: The assertion DoFn runs over the counted PCollection and an element's actual count != f.Count, i.e. the pipeline produced a different occurrence count for some key than expected.

Common situations: Pipeline aggregation logic changed (filters added/removed, dedup changes); expected counts hardcoded against an older dataset; nondeterministic test input.

Related errors

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