apache/cassandra · error · InvalidRequestException

Type error: cannot assign result of function %s (type %s) to

Error message

Type error: cannot assign result of function %s (type %s) to %s (type %s)

What it means

Same receiver-assignability check as the operation variant, but for regular (non-operation) scalar functions: the resolved function's return type cannot be assigned to the receiver column/spec type, so prepare() throws this type error naming the function, its return type, and the receiver.

Source

Thrown at src/java/org/apache/cassandra/cql3/functions/FunctionCall.java:177

        {
            Function fun = FunctionResolver.get(keyspace, name, terms, receiver.ksName, receiver.cfName, receiver.type, UserFunctions.getCurrentUserFunctions(name, keyspace));
            if (fun == null)
                throw invalidRequest("Unknown function %s called", name);
            if (fun.isAggregate())
                throw invalidRequest("Aggregation function are not supported in the where clause");

            ScalarFunction scalarFun = (ScalarFunction) fun;

            // Functions.get() will complain if no function "name" type check with the provided arguments.
            // We still have to validate that the return type matches however
            if (!scalarFun.testAssignment(keyspace, receiver).isAssignable())
            {
                if (OperationFcts.isOperation(name))
                    throw invalidRequest("Type error: cannot assign result of operation %s (type %s) to %s (type %s)",
                                         OperationFcts.getOperator(scalarFun.name()), scalarFun.returnType().asCQL3Type(),
                                         receiver.name, receiver.type.asCQL3Type());

                throw invalidRequest("Type error: cannot assign result of function %s (type %s) to %s (type %s)",
                                     scalarFun.name(), scalarFun.returnType().asCQL3Type(),
                                     receiver.name, receiver.type.asCQL3Type());
            }

            if (fun.argTypes().size() != terms.size())
                throw invalidRequest("Incorrect number of arguments specified for function %s (expected %d, found %d)",
                                     fun, fun.argTypes().size(), terms.size());

            List<Term> parameters = new ArrayList<>(terms.size());
            for (int i = 0; i < terms.size(); i++)
            {
                Term t = terms.get(i).prepare(keyspace, FunctionResolver.makeArgSpec(receiver.ksName, receiver.cfName, scalarFun, i));
                parameters.add(t);
            }

            return new FunctionCall(scalarFun, parameters);
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Make the function return type match the receiver type (ALTER/RECREATE the UDF or pick a different native function)
Compare against a column of the function's return type
Wrap the result in a converting function (e.g. toTimestamp(...)) so types line up

Example fix

// before
SELECT * FROM t WHERE intcol = someUuidFunc();
// after
SELECT * FROM t WHERE uuidcol = someUuidFunc();

Defensive patterns

Strategy: validation

Validate before calling

const fnReturn = await getFunctionReturnType(keyspace, fname); // from system_schema.functions
if (fnReturn !== receiverColumnType) throw new Error(`function returns ${fnReturn}, receiver expects ${receiverColumnType}`);

Try / catch

try { rs = session.execute(q); } catch (InvalidRequestException e) { if (e.getMessage().includes('cannot assign result of function')) { /* align return type with receiver */ } else throw e; }

Prevention

Keep UDF return types synchronized with the queries that use them
Wrap results in conversion functions (toTimestamp, toInt) when types differ

When it happens

Trigger: e.g. `SELECT * FROM t WHERE intcol = uuidFunc()` — the function returns UUID but the compared column is int; or a UDF returning text compared against a timestamp column.

Common situations: UDF return type changed after creation while queries still assume the old type; comparing function results against columns of a different type; misusing native functions like toTimestamp vs toDate.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/e6c3bda308b319ab. Report an issue: GitHub.