n8n-io/n8n · error · Error

Node type ${nodeType} not found

Error message

Node type ${nodeType} not found

What it means

Thrown by the stub node-catalogue's getDescription when asked for a nodeType that has no entry in the descriptionsByName map built from the loaded catalogue file. The stub mirrors production's NodeDescription lookup; an unknown type cannot be described.

Source

Thrown at packages/@n8n/instance-ai/evaluations/harness/stub-services.ts:175

					// version to the agent.
					version: Array.isArray(node.version)
						? (node.version[node.version.length - 1] ?? 1)
						: node.version,
				};
			});
			if (!opts?.query) return all;
			const q = opts.query.toLowerCase();
			return all.filter(
				(n) =>
					n.displayName.toLowerCase().includes(q) ||
					n.name.toLowerCase().includes(q) ||
					n.description.toLowerCase().includes(q),
			);
		},
		async getDescription(nodeType: string) {
			const desc = descriptionsByName.get(nodeType);
			if (!desc) {
				throw new Error(`Node type ${nodeType} not found`);
			}
			return desc;
		},
		async listSearchable() {
			return searchableNodes;
		},
		// Real type-definition source from `dist/node-definitions/`. Falls back
		// to a clear message when the nodes packages haven't been built yet
		// (`pnpm build` from the repo root produces them) — matches production's
		// behavior when node-definition dirs are missing.
		getNodeTypeDefinition: async (nodeType, opts) => {
			if (nodeDefinitionDirs.length === 0) {
				return {
					content: '',
					error:
						'Node type definitions are not available in this eval run. ' +
						'Run `pnpm build` in packages/nodes-base and packages/@n8n/nodes-langchain ' +
						'to generate dist/node-definitions/.',

View on GitHub (pinned to 5ac6606e81)

Solutions

  1. Regenerate the node catalogue (run `pnpm export:nodes` in packages/@n8n/ai-workflow-builder.ee) so it includes the missing node.
  2. Pass the correct internal node `name`, not the displayName.
  3. Verify the catalogue file the harness loaded actually contains an entry for the requested nodeType.

Example fix

// before — requesting a displayName not in the catalogue
client.getDescription('Schedule Trigger'); // displayName

// after — use the internal name and regenerate the catalogue if missing
client.getDescription('n8n-nodes-base.scheduleTrigger');
Defensive patterns

Strategy: validation

Validate before calling

function nodeTypeKnown(nodeType: string, descriptionsByName: Map<string, unknown>): boolean {
  return descriptionsByName.has(nodeType);
}

if (!nodeTypeKnown(nodeType, descriptionsByName)) {
  throw new Error(`nodeType ${nodeType} not in catalogue; regenerate with pnpm export:nodes`);
}

Type guard

function isKnownNodeType(nodeType: string, names: Set<string>): boolean {
  return names.has(nodeType);
}

Try / catch

try {
  await client.getDescription(nodeType);
} catch (e) {
  if (e instanceof Error && /Node type .* not found/.test(e.message)) {
    // regenerate catalogue or use the internal node name, then retry
  }
  throw e;
}

Prevention

When it happens

Trigger: The agent/tool requests a nodeType string that was not present in the catalogue JSON used to build the stub; the nodeType uses a different versioned name (e.g. with a version suffix); the catalogue was generated from a build that did not include the node.

Common situations: Running evals with a stale catalogue after a new node was added to nodes-base; requesting a node by its display name instead of its internal `name`; a typo in the nodeType string.

Related errors


AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12). Data as JSON: /api/errors/f0b0a63a95f407d7. Report an issue: GitHub.