hashicorp/terraform · error

can't compute sum of opposing infinities

Error message

can't compute sum of opposing infinities

What it means

Thrown by the `sum()` collection function (SumFunc) when the underlying big.Float arithmetic panics with big.ErrNaN, which math/big raises when adding opposing-signed infinities (+Inf and -Inf). A deferred recover() in the implementation catches the panic and converts it into this clean error so the panic never escapes the cty function abstraction. It is a genuine user-facing error: summing a list that contains both positive and negative infinity is mathematically undefined.

Source

Thrown at internal/lang/funcs/collection.go:532

		arg := args[0].AsValueSlice()
		ty := args[0].Type()

		if !ty.IsListType() && !ty.IsSetType() && !ty.IsTupleType() {
			return cty.NilVal, function.NewArgErrorf(0, "argument must be list, set, or tuple. Received %s", ty.FriendlyName())
		}

		if !args[0].IsWhollyKnown() {
			return cty.UnknownVal(cty.Number), nil
		}

		// big.Float.Add can panic if the input values are opposing infinities,
		// so we must catch that here in order to remain within
		// the cty Function abstraction.
		defer func() {
			if r := recover(); r != nil {
				if _, ok := r.(big.ErrNaN); ok {
					ret = cty.NilVal
					err = fmt.Errorf("can't compute sum of opposing infinities")
				} else {
					// not a panic we recognize
					panic(r)
				}
			}
		}()

		s := arg[0]
		if s.IsNull() {
			return cty.NilVal, function.NewArgErrorf(0, "argument must be list, set, or tuple of number values")
		}
		s, err = convert.Convert(s, cty.Number)
		if err != nil {
			return cty.NilVal, function.NewArgErrorf(0, "argument must be list, set, or tuple of number values")
		}
		for _, v := range arg[1:] {
			if v.IsNull() {
				return cty.NilVal, function.NewArgErrorf(0, "argument must be list, set, or tuple of number values")

View on GitHub (pinned to c9def3e214)

Solutions

  1. Filter out non-finite values before summing, e.g. `sum([for v in var.nums : v if v == v && v != floor(v) - floor(v)])` or a `compact`/guard to drop infinities.
  2. Clamp or bound the source values so they never reach +/-Inf (cap divisors away from zero, cap exponents).
  3. If one infinity is expected, replace `sum()` with explicit conditional logic that handles the infinite case.
  4. Check the producing provider/resource for an overflow bug that emits Infinity where a finite value was intended.

Example fix

// before
locals {
  total = sum(var.quotients)
}

// after: drop non-finite values before summing
locals {
  finite = [for q in var.quotients : q if can(q * 0 == 0) && q != signum(q) * 1e308 * 1e308]
  total  = length(local.finite) > 0 ? sum(local.finite) : null
}
Defensive patterns

Strategy: validation

Validate before calling

// HCL: filter out non-finite values before sum()
locals {
  nums = [for v in var.values : v if can(v == 0) && !(v > 1e308 * 1e308) && !(v < -1e308 * 1e308)]
  total = length(local.nums) > 0 ? sum(local.nums) : 0
}

Type guard

// HCL guard: detect mixed-sign infinities that would conflict
locals {
  has_pos_inf = anytrue([for v in var.values : v > 1e308 * 1e308])
  has_neg_inf = anytrue([for v in var.values : v < -1e308 * 1e308])
  safe        = !(local.has_pos_inf && local.has_neg_inf)
}

Prevention

When it happens

Trigger: Calling `sum([...])` in HCL where the list contains values whose magnitudes overflow cty.Number to +Inf and -Inf, or a provider emits explicit infinite values of opposite signs. For example `sum([1e400 * 1e400, -1e400 * 1e400])` where both operands overflow to opposing infinities, or `sum([1/0, -1/0])`.

Common situations: Aggregating provider-computed numeric fields that occasionally divide by zero or overflow; summing monetary/resource counters that become unbounded; mixing legacy values that degraded to infinities during provider upgrades.

Related errors


AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/9e89d740edf4d7fa. Report an issue: GitHub.