| name | n8n-validation-expert |
| description | Interpret validation errors and guide fixing them. Use when encountering validation errors, validation warnings, false positives, operator structure issues, or need help understanding validation results. Also use when asking about validation profiles, error types, or the validation loop process. |
n8n Validation Expert
Expert guide for interpreting and fixing n8n validation errors.
Validation Philosophy
Validate early, validate often
Validation is typically iterative:
- Expect validation feedback loops
- Usually 2-3 validate → fix cycles
- Average: 23s thinking about errors, 58s fixing them
Key insight: Validation is an iterative process, not one-shot!
Error Severity Levels
1. Errors (Must Fix)
Blocks workflow execution - Must be resolved before activation
Types:
missing_required - Required field not provided
invalid_value - Value doesn't match allowed options
type_mismatch - Wrong data type (string instead of number)
invalid_reference - Referenced node doesn't exist
invalid_expression - Expression syntax error
Example:
{
"type": "missing_required",
"property": "channel",
"message": "Channel name is required",
"fix": "Provide a channel name (lowercase, no spaces, 1-80 characters)"
}
2. Warnings (Should Fix)
Doesn't block execution - Workflow can be activated but may have issues
Types:
best_practice - Recommended but not required
deprecated - Using old API/feature
performance - Potential performance issue
Example:
{
"type": "best_practice",
"property": "errorHandling",
"message": "Slack API can have rate limits",
"suggestion": "Add onError: 'continueRegularOutput' with retryOnFail"
}
3. Suggestions (Optional)
Nice to have - Improvements that could enhance workflow
Types:
optimization - Could be more efficient
alternative - Better way to achieve same result
The Validation Loop
Pattern from Telemetry
7,841 occurrences of this pattern:
1. Configure node
↓
2. validate_node_operation (23 seconds thinking about errors)
↓
3. Read error messages carefully
↓
4. Fix errors
↓
5. validate_node_operation again (58 seconds fixing)
↓
6. Repeat until valid (usually 2-3 iterations)
Example
let config = {
resource: "channel",
operation: "create"
};
const result1 = validate_node_operation({
nodeType: "nodes-base.slack",
config,
profile: "runtime"
});
config.name = "general";
const result2 = validate_node_operation({
nodeType: "nodes-base.slack",
config,
profile: "runtime"
});
config.text = "Hello!";
const result3 = validate_node_operation({
nodeType: "nodes-base.slack",
config,
profile: "runtime"
});
This is normal! Don't be discouraged by multiple iterations.
Validation Profiles
Choose the right profile for your stage:
minimal
Use when: Quick checks during editing
Validates:
- Only required fields
- Basic structure
Pros: Fastest, most permissive
Cons: May miss issues
runtime (RECOMMENDED)
Use when: Pre-deployment validation
Validates:
- Required fields
- Value types
- Allowed values
- Basic dependencies
Pros: Balanced, catches real errors
Cons: Some edge cases missed
This is the recommended profile for most use cases
ai-friendly
Use when: AI-generated configurations
Validates:
- Same as runtime
- Reduces false positives
- More tolerant of minor issues
Pros: Less noisy for AI workflows
Cons: May allow some questionable configs
strict
Use when: Production deployment, critical workflows
Validates:
- Everything
- Best practices
- Performance concerns
- Security issues
Pros: Maximum safety
Cons: Many warnings, some false positives
Common Error Types
1. missing_required
What it means: A required field is not provided
How to fix:
- Use
get_node_essentials to see required fields
- Add the missing field to your configuration
- Provide an appropriate value
Example:
{
"type": "missing_required",
"property": "channel",
"message": "Channel name is required"
}
config.channel = "#general";
2. invalid_value
What it means: Value doesn't match allowed options
How to fix:
- Check error message for allowed values
- Use
get_node_essentials to see options
- Update to a valid value
Example:
{
"type": "invalid_value",
"property": "operation",
"message": "Operation must be one of: post, update, delete",
"current": "send"
}
config.operation = "post";
3. type_mismatch
What it means: Wrong data type for field
How to fix:
- Check expected type in error message
- Convert value to correct type
Example:
{
"type": "type_mismatch",
"property": "limit",
"message": "Expected number, got string",
"current": "100"
}
config.limit = 100;
4. invalid_expression
What it means: Expression syntax error
How to fix:
- Use n8n Expression Syntax skill
- Check for missing
{{}} or typos
- Verify node/field references
Example:
{
"type": "invalid_expression",
"property": "text",
"message": "Invalid expression: $json.name",
"current": "$json.name"
}
config.text = "={{$json.name}}";
5. invalid_reference
What it means: Referenced node doesn't exist
How to fix:
- Check node name spelling
- Verify node exists in workflow
- Update reference to correct name
Example:
{
"type": "invalid_reference",
"property": "expression",
"message": "Node 'HTTP Requets' does not exist",
"current": "={{$node['HTTP Requets'].json.data}}"
}
config.expression = "={{$node['HTTP Request'].json.data}}";
Auto-Sanitization System
What It Does
Automatically fixes common operator structure issues on ANY workflow update
Runs when:
n8n_create_workflow
n8n_update_partial_workflow
- Any workflow save operation
What It Fixes
1. Binary Operators (Two Values)
Operators: equals, notEquals, contains, notContains, greaterThan, lessThan, startsWith, endsWith
Fix: Removes singleValue property (binary operators compare two values)
Before:
{
"type": "boolean",
"operation": "equals",
"singleValue": true
}
After (automatic):
{
"type": "boolean",
"operation": "equals"
}
2. Unary Operators (One Value)
Operators: isEmpty, isNotEmpty, true, false
Fix: Adds singleValue: true (unary operators check single value)
Before:
{
"type": "boolean",
"operation": "isEmpty"
}
After (automatic):
{
"type": "boolean",
"operation": "isEmpty",
"singleValue": true
}
3. IF/Switch Metadata
Fix: Adds complete conditions.options metadata for IF v2.2+ and Switch v3.2+
What It CANNOT Fix
1. Broken Connections
References to non-existent nodes
Solution: Use cleanStaleConnections operation in n8n_update_partial_workflow
2. Branch Count Mismatches
3 Switch rules but only 2 output connections
Solution: Add missing connections or remove extra rules
3. Paradoxical Corrupt States
API returns corrupt data but rejects updates
Solution: May require manual database intervention
False Positives
What Are They?
Validation warnings that are technically "wrong" but acceptable in your use case
Common False Positives
1. "Missing error handling"
Warning: No error handling configured
When acceptable:
- Simple workflows where failures are obvious
- Testing/development workflows
- Non-critical notifications
When to fix: Production workflows handling important data
2. "No retry logic"
Warning: Node doesn't retry on failure
When acceptable:
- APIs with their own retry logic
- Idempotent operations
- Manual trigger workflows
When to fix: Flaky external services, production automation
3. "Missing rate limiting"
Warning: No rate limiting for API calls
When acceptable:
- Internal APIs with no limits
- Low-volume workflows
- APIs with server-side rate limiting
When to fix: Public APIs, high-volume workflows
4. "Unbounded query"
Warning: SELECT without LIMIT
When acceptable:
- Small known datasets
- Aggregation queries
- Development/testing
When to fix: Production queries on large tables
Reducing False Positives
Use ai-friendly profile:
validate_node_operation({
nodeType: "nodes-base.slack",
config: {...},
profile: "ai-friendly"
})
Validation Result Structure
Complete Response
{
"valid": false,
"errors": [
{
"type": "missing_required",
"property": "channel",
"message": "Channel name is required",
"fix": "Provide a channel name (lowercase, no spaces)"
}
],
"warnings": [
{
"type": "best_practice",
"property": "errorHandling",
"message": "Slack API can have rate limits",
"suggestion": "Add onError: 'continueRegularOutput'"
}
],
"suggestions": [
{
"type": "optimization",
"message": "Consider using batch operations for multiple messages"
}
],
"summary": {
"hasErrors": true,
"errorCount": 1,
"warningCount": 1,
"suggestionCount": 1
}
}
How to Read It
1. Check valid field
if (result.valid) {
} else {
}
2. Fix errors first
result.errors.forEach(error => {
console.log(`Error in ${error.property}: ${error.message}`);
console.log(`Fix: ${error.fix}`);