FlowiseAI/Flowise · error · Error

Unsupported modifier: ${modifier.name}

Error message

Unsupported modifier: ${modifier.name}

What it means

validateTypeInfo requires every modifier name to be in ALLOWED_TYPES = [string, number, int, boolean, date, object, array, enum, optional, max, min, describe, default]. So .email(), .url(), .regex(), .nonempty(), .length(), .transform(), .refine() all fail; only modifiers in the list (e.g. .optional, .max, .min, .int, .describe, .default, .array) pass validation. Note the list conflates base types and modifiers by design.

Source

Thrown at packages/components/src/secureZodParser.ts:298

            }
            return
        }

        // If it's a simple array, validate the inner type
        if (typeInfo.isSimpleArray) {
            this.validateTypeInfo(typeInfo.innerType)
            return
        }

        // Validate base type
        if (!this.ALLOWED_TYPES.includes(typeInfo.base)) {
            throw new Error(`Unsupported type: ${typeInfo.base}`)
        }

        // Validate modifiers
        for (const modifier of typeInfo.modifiers || []) {
            if (!this.ALLOWED_TYPES.includes(modifier.name)) {
                throw new Error(`Unsupported modifier: ${modifier.name}`)
            }
        }
    }

    private static parseArguments(argsStr: string): any[] {
        // Remove outer parentheses
        const inner = argsStr.slice(1, -1).trim()
        if (!inner) return []

        // Simple argument parsing for basic cases
        if (inner.startsWith('[') && inner.endsWith(']')) {
            // Array argument
            const arrayContent = inner.slice(1, -1)
            return [this.parseArrayContent(arrayContent)]
        } else if (inner.match(/^\d+$/)) {
            // Number argument
            return [parseInt(inner, 10)]
        } else if (inner.startsWith('"') && inner.endsWith('"')) {

View on GitHub (pinned to abe4a8601a)

Solutions

  1. Drop unsupported modifiers and enforce constraints via the allowed ones (.max, .min, .describe, .default, .optional).
  2. For format validation (email/url), validate in your own code on the parsed value instead of in the schema string.
  3. If you control the parser, extend ALLOWED_TYPES and add a case in applyModifiers for the new modifier.

Example fix

// before
'z.object({ email: z.string().email() })'

// after
'z.object({ email: z.string().max(254).describe("email") })' // format checked in app code
Defensive patterns

Strategy: type-guard

Validate before calling

const SUPPORTED_MODS = new Set(['optional','max','min','int','describe','default','array'])
function onlyAllowedModifiers(schema: string): boolean {
  return !/\.(email|url|regex|nonempty|length|transform|refine|includes|startsWith|endsWith|ip|cuid|uuid|datetime)\b/.test(schema)
}

Type guard

const SUPPORTED = new Set(['string','number','int','boolean','date','object','array','enum','optional','max','min','describe','default'])
const isAllowedModifier = (name: string): boolean => SUPPORTED.has(name)

Prevention

When it happens

Trigger: Chaining format/refinement validators like '.email()', '.url()', '.regex(/.../)', '.nonempty()', '.length(5)', '.transform(...)', '.refine(...)'.

Common situations: Bringing in validation idioms from full Zod; enforcing email/url formats via modifiers.

Related errors


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