dgraph-io/dgraph · error

Float out of int64 range

Error message

Float out of int64 range

What it means

types.Convert raises this when converting a FloatID value to IntID and the float is NaN, exceeds math.MaxInt64, or is below math.MinInt64, so no lossless int64 representation exists. The library refuses silently truncating or wrapping the value. It is a range/validity check, not an arithmetic bug.

Source

Thrown at types/conversion.go:323

				return to, errors.Errorf("invalid data for float %v", data)
			}
			i := binary.LittleEndian.Uint64(data)
			vc := math.Float64frombits(i)
			switch toID {
			case FloatID:
				*res = vc
			case BigFloatID:
				var b big.Float
				b.SetPrec(BigFloatPrecision).SetFloat64(vc)
				*res = b
			case BinaryID:
				var bs [8]byte
				u := math.Float64bits(vc)
				binary.LittleEndian.PutUint64(bs[:], u)
				*res = bs[:]
			case IntID:
				if vc > math.MaxInt64 || vc < math.MinInt64 || math.IsNaN(vc) {
					return to, errors.Errorf("Float out of int64 range")
				}
				*res = int64(vc)
			case BoolID:
				*res = vc != 0
			case StringID, DefaultID:
				*res = strconv.FormatFloat(vc, 'G', -1, 64)
			case DateTimeID:
				secs := int64(vc)
				fracSecs := vc - float64(secs)
				nsecs := int64(fracSecs * nanoSecondsInSec)
				*res = time.Unix(secs, nsecs).UTC()
			case VFloatID:
				*res = []float32{float32(vc)}
			default:
				return to, cantConvert(fromID, toID)
			}
		}
	case BoolID:

View on GitHub (pinned to 759e242be6)

Solutions

1. Clamp or validate the float before conversion: if math.IsNaN(vc) || vc > math.MaxInt64 || vc < math.MinInt64, handle explicitly
2. Fix the source data (cap the value or store as float/string) rather than casting the predicate type
3. Change the schema so the predicate remains float if values legitimately exceed int64 range

Example fix

// before
types.Convert(types.Val{Tid: types.FloatID, Value: hugeFloat}, &out) // out is IntID
// after
if !math.IsNaN(hugeFloat) && hugeFloat <= math.MaxInt64 && hugeFloat >= math.MinInt64 {
    types.Convert(types.Val{Tid: types.FloatID, Value: hugeFloat}, &out)
} else {
    hugeFloat = math.MaxInt64 // or surface a user-facing error
}

func floatFitsInt64(v float64) bool {
    return !math.IsNaN(v) && !math.IsInf(v, 0) && v <= math.MaxInt64 && v >= math.MinInt64
}
if floatFitsInt64(vc) { types.Convert(...) }

func canConvertFloatToInt(v types.Val) bool {
    f, ok := v.Value.(float64)
    return ok && !math.IsNaN(f) && f >= math.MinInt64 && f <= math.MaxInt64
}

var out types.Val
if err := types.Convert(in, &out); err != nil && strings.Contains(err.Error(), "Float out of int64 range") {
    // clamp or surface a user-facing range error
}

When it happens

Trigger: types.Convert from FloatID to IntID where the source float64 is math.NaN(), ±Inf, or |v| > 2^63 (e.g. 1e300), typically via a schema cast or query coercion of an out-of-range float.

Common situations: Schema migrations changing a predicate from float to int when data contains 1e300 or NaN; computed values overflowing int64; JSON imports with huge floats into int predicates.

Related errors

• error interpreting appropriate type for %v
• Expected value of type int64. Got : %v
• Expected a float but got %v
• Unsupported floating point number in float field
• Leaf predicate:'%v' must be a scalar.

AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/09ce41ee4c95c1f9. Report an issue: GitHub.