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
- Regenerate the node catalogue (run `pnpm export:nodes` in packages/@n8n/ai-workflow-builder.ee) so it includes the missing node.
- Pass the correct internal node `name`, not the displayName.
- 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
- Regenerate the catalogue whenever nodes-base changes.
- Always pass the internal node `name`, not displayName.
- Ship the catalogue as a build artefact in CI.
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
- Could not read node catalogue at ${jsonPath}: ${message} Run
- No runs for thread ${ref.threadId} in LangSmith project "${s
- Thread ${ref.threadId}: the live turn is the first/only user
- A case declares ${String(byName.size)} distinct scenario see
- Model ID is required
AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12).
Data as JSON: /api/errors/f0b0a63a95f407d7.
Report an issue: GitHub.