n8n-io/n8n · error · NodeOperationError

Error: ${error.message}

Error message

Error: ${error.message}

What it means

A catch-all wrapper in populateVectorStore around ExtendedRedisVectorSearch.fromDocuments. Any error raised while inserting documents into Redis is logged at info level and re-thrown as a NodeOperationError echoing the original message. The original cause is in error.message and the log line.

Source

Thrown at packages/@n8n/nodes-langchain/nodes/vector_store/VectorStoreRedis/VectorStoreRedis.node.ts:407

			const embeddingField = getEmbeddingKey(context, itemIndex).trim();
			const ttl = getTtl(context, itemIndex);

			if (overwrite) {
				await client.ft.dropIndex(indexField, { DD: true });
			}

			await ExtendedRedisVectorSearch.fromDocuments(documents, embeddings, {
				redisClient: client,
				indexName: indexField,
				...(keyPrefixField ? { keyPrefix: keyPrefixField } : {}),
				...(metadataField ? { metadataKey: metadataField } : {}),
				...(contentField ? { contentKey: contentField } : {}),
				...(embeddingField ? { vectorKey: embeddingField } : {}),
				...(ttl ? { ttl } : {}),
			});
		} catch (error) {
			context.logger.info(`Error while populating the store: ${error.message}`);
			throw new NodeOperationError(context.getNode(), `Error: ${error.message}`, {
				itemIndex,
				description: 'Please check your index/schema and parameters',
			});
		}
	},
}) {}

View on GitHub (pinned to 5ac6606e81)

Solutions

1. Read the full underlying error in the node output / n8n logs (the wrapped error.message) — it names the real cause (dimension mismatch, wrong type, etc.).
2. If it is a dimension mismatch, drop and recreate the index with a VECTOR field matching the new embedding dimension, then re-run Insert.
3. Align the node's keyPrefix/metadataKey/contentKey/vectorKey options with the FT.CREATE SCHEMA fields.
4. Validate TTL is a positive integer supported by your Redis; remove it if unsupported.
5. Check Redis INFO memory and slowlog if the failure looks resource-related.

Example fix

// before: index SCHEMA VECTOR field HNSW DIMENSION 1536, new embeddings are 3072-dim
// after:  drop & recreate:
//   FT.DROPINDEX myindex
//   FT.CREATE myindex ON HASH PREFIX 1 doc: SCHEMA content TEXT vector VECTOR HNSW DIMENSION 3072 DISTANCE_METRIC COSINE

// validate dimensions + schema keys match the index before populating
function assertSchemaCompat(opts: { metadataKey: string; contentKey: string; vectorKey: string }, dim: number, indexDim: number) {
  if (dim !== indexDim) throw new Error(`embedding dim ${dim} != index VECTOR dim ${indexDim}`);
  for (const k of Object.values(opts)) if (!k) throw new Error(`Empty schema key: ${JSON.stringify(opts)}`);
}

function isPositiveTtl(ttl: unknown): ttl is number { return typeof ttl === 'number' && ttl > 0 && Number.isFinite(ttl); }

try { await store.populateVectorStore(...) } catch (e) { logOriginal(e); throw new Error(`Populate failed: ${e.message}`); }

When it happens

Trigger: fromDocuments fails during populate — e.g. embedding vector dimension does not match the index SCHEMA VECTOR field dimension; key prefix/metadata/content/vector key options conflict with the index schema; TTL invalid; Redis write rejected (OOM, wrong type, permission); RediSearch schema mismatch.

Common situations: Switched embedding model so vector dimensions changed but the index was not rebuilt; index created with a different SCHEMA than the current keyPrefix/metadataKey/contentKey/vectorKey options; TTL set on a Redis version/config that disallows it; oversized payload or Redis maxmemory eviction.

Related errors

• Redis client not initialized
• Index ${indexField} not found
• ${error.message}
• Tool "${this.name}" requires an input schema
• Invalid filter operator "${operator}" for key "${key}". Supp

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