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
- Drop unsupported modifiers and enforce constraints via the allowed ones (.max, .min, .describe, .default, .optional).
- For format validation (email/url), validate in your own code on the parsed value instead of in the schema string.
- 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
- Use only modifiers in ALLOWED_TYPES: .optional, .max, .min, .int, .describe, .default, .array.
- Enforce format constraints (email/url/regex) in application code on the parsed value.
- If you own the parser, extend ALLOWED_TYPES and add a matching case in applyModifiers.
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
- Unsupported type: ${typeInfo.base}
- Error parsing Zod Schema: ${exception}
- Received tool input did not match expected schema: ${JSON.st
- Received tool input did not match expected schema: ${JSON.st
- Received tool input did not match expected schema
AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12).
Data as JSON: /api/errors/a017573255e34799.
Report an issue: GitHub.