apache/beam · error
values below minimum value %v: %v
Error message
values below minimum value %v: %v
What it means
passert.AllWithinBounds's ProcessElement collects observed values outside the [Lo, Hi] range; values under the minimum are sorted and reported as 'values below minimum value %v: %v', listing Lo and the offending values. It fails the assertion when the PCollection contains any element outside the specified bounds.
Source
Thrown at sdks/go/pkg/beam/testing/passert/floats.go:151
if val < f.Lo {
tooLow = append(tooLow, val)
} else if val > f.Hi {
tooHigh = append(tooHigh, val)
}
}
if len(tooLow)+len(tooHigh) == 0 {
return nil
}
errorStrings := []string{}
if len(tooLow) != 0 {
sort.Float64s(tooLow)
errorStrings = append(errorStrings, fmt.Sprintf("values below minimum value %v: %v", f.Lo, tooLow))
}
if len(tooHigh) != 0 {
sort.Float64s(tooHigh)
errorStrings = append(errorStrings, fmt.Sprintf("values above maximum value %v: %v", f.Hi, tooHigh))
}
return errors.New(strings.Join(errorStrings, "\n"))
}
func toFloat(input beam.T) float64 {
return reflect.ValueOf(input.(any)).Convert(reflectx.Float64).Interface().(float64)
}
func validateNonComplexNumber(t reflect.Type) error {
if !reflectx.IsNumber(t) || reflectx.IsComplex(t) {
return errors.Errorf("type must be a non-complex number: %v", t)
}
return nil
}
View on GitHub (pinned to 12126d8942)
Solutions
- Inspect the listed out-of-range values to find the producing stage
- Fix upstream logic so values respect the bounds (clamping, validation ParDo)
- Adjust lo/hi arguments if the intended bounds were wrong (note the function swaps flipped bounds already)
- Add a filter/validator transform if out-of-range values are expected to be dropped
Example fix
// before
passert.AllWithinBounds(s, ratios, 0.0, 1.0) // values below minimum value 0: [-0.02]
// after
safe := beam.ParDo(s, &clampToUnitIntervalFn{}, ratios)
passert.AllWithinBounds(s, safe, 0.0, 1.0) Defensive patterns
Strategy: validation
Validate before calling
// pre-filter or clamp values that may exceed bounds before asserting
clamped := beam.ParDo(s, &clampFn{Lo: 0.0, Hi: 1.0}, col) Try / catch
if got := assertAllWithinBounds(col, 0.0, 1.0); got != nil {
t.Fatalf("out-of-bounds values: %v", got)
} Prevention
- Validate value ranges in a dedicated ParDo before the assertion
- Remember AllWithinBounds swaps flipped lo/hi arguments — pass them in order
- Inspect the sorted offending values list to find the producing transform
- Drop or clamp expected outliers with a filter transform
When it happens
Trigger: Calling passert.AllWithinBounds(s, col, lo, hi) where at least one observed value is < lo — e.g. negative values where only non-negatives were expected.
Common situations: Validating metric PCollections (percentages, counts) that unexpectedly go out of range; divide/aggregation bugs producing out-of-range numbers; unsorted outliers reported verbatim in the error.
Understand the failure class
Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.
Related errors
- %d missing entries (missing in actual, present in expected)
- observed PCollection has incompatible type: %v
- values below expected: %v
- passert.Count(%v) = %v, want %v
- PCollections of different lengths, got %v expected %v
AI-assisted analysis of apache/beam@12126d8942 (2026-09-13).
Data as JSON: /api/errors/4bd1db22baa1d54d.
Report an issue: GitHub.