dgraph-io/dgraph · error

Wrong type %v encountered for func ln

Error message

Wrong type %v encountered for func ln

What it means

The `ln` unary math function in the Dgraph query aggregator only accepts INT, FLOAT, and BIGFLOAT typed values. When the argument's type ID (a.Tid) falls through to the DEFAULT case — e.g. a string, bool, datetime, or default-typed value — the aggregator returns this error instead of computing a logarithm. It reports the offending type ID so the caller can see which type was unexpected.

Source

Thrown at query/aggregator.go:444

func applyLn(a, res *types.Val) error {
	vBase := getValType(a)
	switch vBase {
	case INT:
		if a.Value.(int64) < 0 {
			return ErrorNegativeLog
		}
		res.Value = math.Log(float64(a.Value.(int64)))
		res.Tid = types.FloatID

	case FLOAT:
		if a.Value.(float64) < 0 {
			return ErrorNegativeLog
		}
		res.Value = math.Log(a.Value.(float64))

	case DEFAULT:
		return errors.Errorf("Wrong type %v encountered for func ln", a.Tid)
	}
	return nil
}

func applyExp(a, res *types.Val) error {
	vBase := getValType(a)
	switch vBase {
	case INT:
		res.Value = math.Exp(float64(a.Value.(int64)))
		res.Tid = types.FloatID

	case FLOAT:
		res.Value = math.Exp(a.Value.(float64))

	case DEFAULT:
		return errors.Errorf("Wrong type %v encountered for func exp", a.Tid)
	}
	return nil

View on GitHub (pinned to 759e242be6)

Solutions

  1. Ensure the argument to ln() is a numeric predicate (int/float in the schema) or cast via math operations that yield floats
  2. Check the predicate's schema with the /state or schema endpoint to confirm it is numeric
  3. Fix query variables so the value fed to ln is numeric, e.g. use math ln(math.sqrt(x)) only on numeric vars
  4. If the value is optional, filter out nodes where the predicate is absent or non-numeric before aggregating

Example fix

// before: ln over a string predicate
q := `{ me(func: eq(name, "x")) { math ln(score_str) } }`
// after: use a numeric predicate
q := `{ me(func: eq(name, "x")) { math ln(score) } }`
Defensive patterns

Strategy: type-guard

Validate before calling

// ensure value is numeric before running the query
function isNumericPred(schema, pred) {
  const t = schema.find(p => p.predicate === pred).type;
  return t === 'int' || t === 'float';
}

Type guard

function isNumeric(v) {
  return typeof v === 'number' && Number.isFinite(v);
}

Try / catch

try {
  await dgraph.newTxn().query(q);
} catch (e) {
  if (String(e).includes('Wrong type') && String(e).includes('func ln')) {
    // fall back to non-log path or fix operand type
  }
  throw e;
}

Prevention

When it happens

Trigger: Running a Dgraph query with math ln(x) (or an aggregator applying ln) where x evaluates to a non-numeric type: a string predicate, a bool, a dateTime, or a value that could not be coerced to a numeric type by matchType.

Common situations: Developers apply ln() to a string-typed predicate or a facet value; schema of the predicate changed from float to string so values arrive with an unexpected Tid; a variable in the math expression resolves to a non-numeric scalar (e.g. uid or datetime from since()).

Related errors


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