FlowiseAI/Flowise · warning · Error

Invalid evaluator type

Error message

Invalid evaluator type

What it means

EvaluatorDTO.toEntity converts an inbound request body into an Evaluator entity by branching on body.type. Only four types are supported: 'llm', 'text', 'json', 'numeric'. Any other value (including undefined, wrong casing, or a typo) falls through every if/else-if branch and hits the terminal else, throwing 'Invalid evaluator type'. This guards the config JSON shape, since each type assembles different fields into config.

Source

Thrown at packages/server/src/Interface.Evaluation.ts:109

                outputSchema: body.outputSchema
            }
        } else if (body.type === 'text') {
            config = {
                operator: body.operator,
                value: body.value
            }
        } else if (body.type === 'json') {
            config = {
                operator: body.operator
            }
        } else if (body.type === 'numeric') {
            config = {
                operator: body.operator,
                value: body.value,
                measure: body.measure
            }
        } else {
            throw new Error('Invalid evaluator type')
        }
        newDs.config = JSON.stringify(config)
        return newDs
    }

    static fromEntity(entity: Evaluator): EvaluatorDTO {
        const newDs = new EvaluatorDTO()
        Object.assign(newDs, entity)
        const config = JSON.parse(entity.config)
        if (entity.type === 'llm') {
            newDs.prompt = config.prompt
            newDs.outputSchema = config.outputSchema
        } else if (entity.type === 'text') {
            newDs.operator = config.operator
            newDs.value = config.value
        } else if (entity.type === 'json') {
            newDs.operator = config.operator
            newDs.value = config.value

View on GitHub (pinned to abe4a8601a)

Solutions

1. Set body.type to exactly one of 'llm', 'text', 'json', 'numeric' (lowercase) before calling toEntity.
2. If the client legitimately needs a new evaluator type, extend the if/else chain and the fromEntity branch to handle it before sending that value.
3. Add request-level validation (e.g. a schema/enum check) at the controller so an invalid type is rejected with a clear 400 before reaching toEntity.
4. Sanitize/normalize imported evaluator type values to the canonical lowercase set during migration.

Example fix

// before
if (body.type === 'llm') { ... }
else if (body.type === 'text') { ... }
else if (body.type === 'json') { ... }
else if (body.type === 'numeric') { ... }
else { throw new Error('Invalid evaluator type') }

// after: validate up front with an explicit allow-list
const VALID = ['llm', 'text', 'json', 'numeric'] as const
if (!VALID.includes(body.type)) {
    throw new Error(`Invalid evaluator type '${body.type}'. Expected one of: ${VALID.join(', ')}`)
}

const EVALUATOR_TYPES = ['llm', 'text', 'json', 'numeric'] as const
type EvaluatorType = typeof EVALUATOR_TYPES[number]

function assertEvaluatorType(type: unknown): asserts type is EvaluatorType {
    if (!typeof type === 'string' || !(EVALUATOR_TYPES as readonly string[]).includes(type)) {
        throw new Error(`Invalid evaluator type '${type}'. Expected one of: ${EVALUATOR_TYPES.join(', ')}`)
    }
}

// in controller, before calling EvaluatorDTO.toEntity:
assertEvaluatorType(req.body.type)

function isEvaluatorType(type: unknown): type is 'llm' | 'text' | 'json' | 'numeric' {
    return typeof type === 'string' && ['llm', 'text', 'json', 'numeric'].includes(type)
}

try {
    const entity = EvaluatorDTO.toEntity(req.body)
} catch (err) {
    if (err instanceof Error && err.message === 'Invalid evaluator type') {
        return res.status(StatusCodes.BAD_REQUEST).json({ error: err.message, allowed: ['llm', 'text', 'json', 'numeric'] })
    }
    throw err
}

When it happens

Trigger: POST/PUT to an evaluator endpoint with body.type set to an unsupported string (e.g. 'boolean', 'regex', 'LLM' uppercase, or omitted entirely). Importing or migrating evaluator records whose type field doesn't match the four canonical values. A client sending a new evaluator kind before the server supports it.

Common situations: Frontend dropdown sends a type the backend hasn't shipped support for yet. Casing mismatch ('Numeric' vs 'numeric'). Older exported evaluators using a deprecated type label. Programmatic client constructing payloads with a typo in the type field.

Related errors

• Invalid file name: name is required
• Invalid file path: key is required and must be a string
• Invalid input array
• Unknown distance strategy: ${distanceStrategy}
• Failed to parse Supabase filter: ${error.message}

AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12). Data as JSON: /api/errors/cef336bad02a1174. Report an issue: GitHub.