What causes "numpaths value %d exceeds maximum allowed value %d" in dgraph-io/dgraph?

Lower numpaths to a sane bounded value (e.g. 10, 100) matching what you can consume

numpaths value %d exceeds maximum allowed value %d

Error message

numpaths value %d exceeds maximum allowed value %d

What it means

The numpaths argument controls how many shortest/recurse paths Dgraph returns. Because paths are stored in Go slices indexed by int, a numpaths larger than math.MaxInt on the platform cannot be represented; fill() parses the value and rejects anything exceeding that bound at parse time rather than overflowing later.

Source

Thrown at query/query.go:701

		args.AfterUID = after
	}

	if args.Alias == "shortest" {
		if v, ok := gq.Args["depth"]; ok {
			depth, err := strconv.ParseUint(v, 0, 64)
			if err != nil {
				return err
			}
			args.ExploreDepth = &depth
		}

		if v, ok := gq.Args["numpaths"]; ok {
			numPaths, err := strconv.ParseUint(v, 0, 64)
			if err != nil {
				return err
			}
			if numPaths > math.MaxInt {
				return errors.Errorf("numpaths value %d exceeds maximum allowed value %d",
					numPaths, math.MaxInt)
			}
			args.NumPaths = int(numPaths)
		}

		if v, ok := gq.Args["maxweight"]; ok {
			maxWeight, err := strconv.ParseFloat(v, 64)
			if err != nil {
				return err
			}
			args.MaxWeight = maxWeight
		} else if !ok {
			args.MaxWeight = math.MaxFloat64
		}

		if v, ok := gq.Args["minweight"]; ok {
			minWeight, err := strconv.ParseFloat(v, 64)
			if err != nil {

View on GitHub (pinned to 759e242be6)

Solutions

Lower numpaths to a sane bounded value (e.g. 10, 100) matching what you can consume
Omit numpaths entirely to use the default behavior instead of a huge sentinel
Clamp the value client-side before building the query: min(requested, MaxInt64)

Example fix

// before
shortest(from: 0x1, to: 0x2, numpaths: 18446744073709551615)
// after
shortest(from: 0x1, to: 0x2, numpaths: 100)

Defensive patterns

Strategy: validation

Validate before calling

const MAX_NUMPATHS = Number.MAX_SAFE_INTEGER; // aligns with Go math.MaxInt on 64-bit
function setNumPaths(args, n) {
  if (n > MAX_NUMPATHS) throw new Error('numpaths too large; use a bounded value');
  args.numpaths = n;
}

Type guard

const isSafeNumPaths = (n) => Number.isInteger(n) && n >= 0 && n <= Number.MAX_SAFE_INTEGER;

Try / catch

try {
  await txn.query(q);
} catch (e) {
  if (e.message.includes('numpaths value') && e.message.includes('exceeds maximum')) {
    console.error('Clamp numpaths to a realistic value');
  }
  throw e;
}

Prevention

Never use 2^64-1 or other sentinel values for numpaths
Clamp user/config supplied values to a sane upper bound
Omit numpaths when the default is acceptable

When it happens

Trigger: Sending `shortest(from: ..., to: ..., numpaths: 18446744073709551615)` or any value > MaxInt64 on 64-bit (or a huge value like 99999999999999999999 that also fails ParseUint); using numpaths with recurse paths queries.

Common situations: Users passing a sentinel "infinite" value like 2^64-1 expecting unlimited paths; programmatically generated values from unsigned 64-bit config; copy-paste from docs of large numbers.

Related errors

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