UNIMPLEMENTED

UNIMPLEMENTED

Error message

%s: %s (evalengine.ErrTranslateExprNotSupported, sqlparser.String(predicate))

What it means

When planning a filter's predicates with offsets (useOffsets + evalengine.Translate), an error whose message starts with evalengine.ErrTranslateExprNotSupported is converted into a gRPC UNIMPLEMENTED error. It means the filter predicate contains an expression the evalengine translator cannot represent after offset rewriting (unsupported function, construct, or type in the WHERE/HAVING predicate).

Source

Thrown at go/vt/vtgate/planbuilder/operators/filter.go:115

}

func (f *Filter) GetOrdering(ctx *plancontext.PlanningContext) []OrderBy {
	return f.Source.GetOrdering(ctx)
}

func (f *Filter) planOffsets(ctx *plancontext.PlanningContext) Operator {
	cfg := &evalengine.Config{
		ResolveType: ctx.TypeForExpr,
		Collation:   ctx.SemTable.Collation,
		Environment: ctx.VSchema.Environment(),
	}

	predicate := sqlparser.AndExpressions(f.Predicates...)
	rewritten := useOffsets(ctx, predicate, f)
	eexpr, err := evalengine.Translate(rewritten, cfg)
	if err != nil {
		if strings.HasPrefix(err.Error(), evalengine.ErrTranslateExprNotSupported) {
			panic(vterrors.Errorf(vtrpcpb.Code_UNIMPLEMENTED, "%s: %s", evalengine.ErrTranslateExprNotSupported, sqlparser.String(predicate)))
		}
		panic(err)
	}

	f.PredicateWithOffsets = eexpr
	return nil
}

func (f *Filter) ShortDescription() string {
	return sqlparser.String(sqlparser.AndExpressions(f.Predicates...))
}

func (f *Filter) setTruncateColumnCount(offset int) {
	f.ResultColumns = offset
}

func (f *Filter) getTruncateColumnCount() int {
	return f.ResultColumns

View on GitHub (pinned to 01a25a7d17)

Solutions

Read the original predicate in the error message and identify the unsupported expression; rewrite the query to avoid it or compute it outside SQL
Move the unsupported computation out of the filtered predicate (e.g. select it, then filter in application code) or simplify it into supported functions
Check Vitess release notes/evalengine support list; upgrade to a version where the function is supported, or file a feature request

Example fix

// before
SELECT * FROM t1 JOIN t2 ON t1.id = t2.id WHERE MY_CUSTOM_FUNC(t1.x) = 1
// after
SELECT * FROM t1 JOIN t2 ON t1.id = t2.id WHERE t1.x = 1 -- or a supported equivalent expression

Defensive patterns

Strategy: try-catch

Validate before calling

// best-effort pre-check in tooling
_, err := evalengine.Translate(predicate, cfg)
if err != nil && strings.HasPrefix(err.Error(), evalengine.ErrTranslateExprNotSupported) { /* rewrite query beforehand */ }

Try / catch

err := grpcerr.Run(plan) // returns vtrpcpb.Code_UNIMPLEMENTED wrapped error
if code := vterrors.Code(err); code == vtrpcpb.Code_UNIMPLEMENTED {
	// fall back to a simpler query or surface a clear user-facing message
}

Prevention

Keep WHERE predicates to evalengine-supported functions
Test application queries against Vitess with representative predicates
Track evalengine supported-function list per Vitess version before upgrading

When it happens

Trigger: A query's filter predicate, after being rewritten to offset-based expressions for hash-join/filter planning, contains an unsupported construct - e.g. an unsupported function call, subquery remnant, or comparison the evalengine does not translate - triggering the prefix check in planOffsets.

Common situations: Queries using MySQL functions not yet supported by Vitess's evalengine; version upgrades where offset-based filter planning newly touches a predicate; ORMs emitting unusual expressions in WHERE clauses on joins that require offset planning.

Related errors

AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/59527666d0d67869. Report an issue: GitHub.