n8n_create_workflow: unhandled TypeError (toLowerCase / startsWith) on malformed nodes[] entries instead of a validation error

[czlonkowski]

Summary

n8n_create_workflow returns an unhandled TypeError instead of a validation error when the
nodes array contains an entry that is not a well-formed node object and that entry is
referenced from connections.

The error surfaces to the client as:

Cannot read properties of undefined (reading 'toLowerCase')

A related shape returns node.type?.startsWith is not a function.

Both look like connection/type resolution running before (or independently of) the node-shape
validation that already exists and works correctly for the same inputs.

Reproduction

n8n-mcp 2.79.0, node v22.23.2, HTTP transport.

1. Crash — string entry in nodes[] that connections references:

{
  "name": "repro",
  "nodes": [
    {"id": "1", "name": "Manual Trigger", "type": "n8n-nodes-base.manualTrigger",
     "typeVersion": 1, "position": [0, 0], "parameters": {}},
    "strayString"
  ],
  "connections": {
    "Manual Trigger": {"main": [[{"node": "strayString", "type": "main", "index": 0}]]}
  }
}

→ Cannot read properties of undefined (reading 'toLowerCase')

2. Crash — node whose type is not a string:

{
  "name": "repro",
  "nodes": [
    {"id": "1", "name": "Manual Trigger", "type": "n8n-nodes-base.manualTrigger",
     "typeVersion": 1, "position": [0, 0], "parameters": {}},
    {"id": "2", "name": "Num Type", "type": 123, "typeVersion": 1,
     "position": [200, 0], "parameters": {}}
  ],
  "connections": {}
}

→ node.type?.startsWith is not a function

What already works (for contrast)

These same malformed inputs are handled correctly when the bad entry is not wired up, which is
why this reads as a missing guard rather than a missing validator:

Input	Result
String entry in nodes[], not referenced by connections	Workflow validation failed ✅
Node object missing type, not referenced	Workflow validation failed ✅
Connection pointing at a node name that does not exist (all nodes valid)	Workflow validation failed ✅
Connection key naming a node that does not exist	Workflow validation failed ✅
String entry in nodes[] that connections references	TypeError ❌
Node with non-string type	TypeError ❌

validate_workflow handles every one of the above cleanly (valid: false with 2 errors), so the
gap is specific to the create path.

Why it matters

Any client that builds workflow JSON programmatically can emit a malformed nodes entry — a
partially recovered JSON payload, a template that interpolated wrong, a serialisation bug. The
current behaviour turns that into an opaque runtime error that looks like a server fault, so
clients cannot distinguish "my payload was malformed" from "the server is broken", and it is not
actionable without server logs.

Suggested fix

Before connection/type resolution in the create path, reject entries in nodes that are not
objects with string name and type, and surface them through the same
Workflow validation failed response used elsewhere. Optionally guard the accessors
(node?.type?.toLowerCase?.()) as defence in depth.

[github-actions]

🎯 Agentic Issue Triage

Summary

Issue #1071 reports that n8n_create_workflow crashes with unhandled TypeError exceptions (Cannot read properties of undefined (reading 'toLowerCase') and node.type?.startsWith is not a function) when the nodes array contains malformed entries (strings instead of objects, or objects with non-string type) and those entries are referenced from the connections object. The same malformed inputs are handled gracefully when not wired up in connections, or when calling validate_workflow.

Root Cause

The validateWorkflowStructure() function in src/services/n8n-validation.ts validates the general workflow shape and connectivity, but it does not validate that each entry in the nodes array is:

• An object (not a primitive like a string)
• Has a type field that is a string

This validation occurs, but too late: the code in handlers-n8n-manager.ts line 635 tries to call .startsWith() on node.type without first ensuring it is a string. Meanwhile, connection validation and node type resolution happen during the API call or before proper node shape validation, hitting the null/undefined branch and triggering the crash.

Affected Behavior

1. Scenario 1 (crashes): nodes contains a string entry, connections references it
   • Error: Cannot read properties of undefined (reading 'toLowerCase')
2. Scenario 2 (crashes): nodes contains an object where type is not a string (e.g., 123), connections optionally reference it
   • Error: node.type?.startsWith is not a function
3. Contrast (works): Same malformed inputs without connection references
   • Result: Graceful Workflow validation failed error ✅

Debugging & Reproduction Steps

Reproduction Case 1: String entry in nodes[]

{
  "name": "repro-case-1",
  "nodes": [
    {"id": "1", "name": "Manual Trigger", "type": "n8n-nodes-base.manualTrigger", "typeVersion": 1, "position": [0, 0], "parameters": {}},
    "strayString"
  ],
  "connections": {
    "Manual Trigger": {"main": [[{"node": "strayString", "type": "main", "index": 0}]]}
  }
}

Expected: Workflow validation failed with error listing invalid node entry
Actual: TypeError: Cannot read properties of undefined (reading 'toLowerCase')

Reproduction Case 2: Non-string type

{
  "name": "repro-case-2",
  "nodes": [
    {"id": "1", "name": "Manual Trigger", "type": "n8n-nodes-base.manualTrigger", "typeVersion": 1, "position": [0, 0], "parameters": {}},
    {"id": "2", "name": "BadType", "type": 123, "typeVersion": 1, "position": [200, 0], "parameters": {}}
  ],
  "connections": {}
}

Expected: Workflow validation failed with validation error
Actual: TypeError: node.type?.startsWith is not a function

Key Code Locations

• Handler entry point: src/mcp/handlers-n8n-manager.ts line 627–734 (handleCreateWorkflow)
• Short-form type check (crashes): src/mcp/handlers-n8n-manager.ts lines 634–644 tries .startsWith() on any node.type without guard
• Validation function (missing check): src/services/n8n-validation.ts lines 293–410 (validateWorkflowStructure) does not validate node object shape or type string type before connection traversal

Suggested Fix Approach

Implementation Strategy

1. Add early node shape validation to validateWorkflowStructure() before any connection checks:

   • Loop through workflow.nodes once at the start
   • For each entry, ensure it is an object (not a primitive)
   • Ensure required fields (name, type) exist
   • Ensure type is a string
   • Collect and return all shape errors

2. Add defensive guards to the short-form type check in handleCreateWorkflow() (line 634–644):

   • Guard .startsWith() calls: node.type?.startsWith('nodes-base.') is already safe, but make it explicit
   • Or rely on validation passing first

3. Reuse the same error format (Workflow validation failed) so clients cannot distinguish between shape errors and logic errors

4. Test matrix:

   • String entry in nodes[], with and without connection reference
   • Non-string type, with and without connection reference
   • All other malformed inputs already handled by the function

Resources & Patterns

• Validation entry point: src/services/n8n-validation.ts — all workflow structure checks live here
• TypeScript types: src/types/ — check Workflow and Node type definitions to understand the expected shape
• Test fixtures: tests/integration/ or tests/unit/ likely contain workflow validation test cases — can use existing patterns
• Related validator: validate_workflow MCP tool (documented in src/mcp/tool-docs/validation/validate-workflow.ts) already handles these cases correctly, so the gap is specific to the create path

Acceptance Criteria

• ✅ Both reproduction cases return Workflow validation failed with a clear error message
• ✅ Error message specifies which node entry is malformed (index, attempted value, expected shape)
• ✅ All existing validation tests pass
• ✅ New test cases cover both scenarios
• ✅ validate_workflow behavior unchanged (as a control)

Generated by Agentic Triage for issue #1071 · ● 94K · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@13377ddf7e35c2b6e47aa58f45acb228fba902c8