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 nilView on GitHub (pinned to 759e242be6)
Solutions
- Ensure the argument to ln() is a numeric predicate (int/float in the schema) or cast via math operations that yield floats
- Check the predicate's schema with the /state or schema endpoint to confirm it is numeric
- Fix query variables so the value fed to ln is numeric, e.g. use math ln(math.sqrt(x)) only on numeric vars
- 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
- Validate predicate schema types before building math expressions
- Keep numeric math functions away from string/bool/date predicates
- Add query-level tests for every math expression
- Filter null/absent values before aggregation
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
- Wrong type %v encountered for func exp
- Wrong type %v encountered for func u-
- Wrong type %v encountered for func sqrt
- Wrong type %v encountered for func floor
- Wrong type %v encountered for fun ceil
AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01).
Data as JSON: /api/errors/70918044f72443f7.
Report an issue: GitHub.