conductor-oss/conductor · error · RuntimeException
Embeddings must be of dimensions : <embeddingDimensions>
Error message
Embeddings must be of dimensions : <embeddingDimensions>
What it means
Thrown as a plain RuntimeException by PostgresVectorDB.upsertEmbeddings when the provided embeddings list size does not equal the configured embedding dimensions (default 256, from config.getDimensions()). The pgvector column has a fixed dimension, so a mismatched vector cannot be inserted and would fail at the DB anyway; this guard fails early with a clear message.
Source
Thrown at ai/src/main/java/org/conductoross/conductor/ai/vectordb/postgres/PostgresVectorDB.java:192
"Error encountered while updating embeddings as : {}",
exception.getMessage(),
exception);
throw new RuntimeException(exception);
}
}
private int upsertEmbeddings(
String namespace,
String id,
String parentDocId,
String doc,
List<Float> embeddings,
Map<String, Object> metadata,
Connection conn) {
final int embeddingDimensions =
config.getDimensions() != null ? config.getDimensions() : 256;
if (embeddingDimensions != embeddings.size()) {
throw new RuntimeException("Embeddings must be of dimensions : " + embeddingDimensions);
}
String tableName =
config.getTablePrefix() != null
? config.getTablePrefix() + "_" + namespace
: namespace;
String UPSERT_QUERY =
"INSERT INTO "
+ tableName
+ " AS n (id, parent_doc_id, embedding, doc, metadata) "
+ "VALUES (?, ?, ?, ?, ?) "
+ "ON CONFLICT (id) DO UPDATE SET parent_doc_id = ?, embedding = ?, doc = ?, metadata = ? WHERE n.id = ?";
log.debug("Executing upsert query: {}", UPSERT_QUERY);
log.debug(
"Upserting document with id: {}, parentDocId: {}, doc length: {}, embedding dimensions: {}",
id,
parentDocId,
doc.length(),
embeddings.size());View on GitHub (pinned to cf7c3e4a8a)
Solutions
- Align config.getDimensions() (conductor.vectordb.postgres.dimensions) with the embedding model's output dimension.
- Regenerate embeddings with the model whose dimension matches the index, or recreate the index/table at the new dimension.
- Verify the embedding generation step uses the same model/dimensions setting as the index.
- Ensure no other producer writes a different-dimension vector to the same namespace.
Example fix
// before # config: conductor.vectordb.postgres.dimensions=256 # but model outputs 1536 // after conductor.vectordb.postgres.dimensions=1536 # (and recreate the pgvector table/column at the new dimension)
Defensive patterns
Strategy: validation
Validate before calling
// Match the vector dimension to config before upsert
int dim = config.getDimensions() != null ? config.getDimensions() : 256;
if (embeddings.size() != dim) {
throw new IllegalArgumentException("expected " + dim + " dims, got " + embeddings.size());
} Prevention
- Pin conductor.vectordb.postgres.dimensions to the embedding model's output size.
- Use a single embedding model per index.
- Recreate the pgvector table when changing dimensions.
When it happens
Trigger: Upserting embeddings whose length differs from config.getDimensions() (or 256 if unset). Commonly a model/dimension mismatch: e.g. a 1536-dim OpenAI embedding written into a 256-dim index, or a 384-dim MiniLM into a 1536-dim index.
Common situations: Switched embedding model without updating conductor.vectordb.postgres.dimensions; mixed models writing to the same index; dimensions config left at default 256 while using a model with a different output size; chunking code corrupting the vector length.
Related errors
AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14).
Data as JSON: /api/errors/d64aa4ca18b43f70.
Report an issue: GitHub.