dgraph-io/dgraph · error

error creating indexer for %s: %w

Error message

error creating indexer for %s: %w

What it means

During bulk vector indexing, getOrCreateIndexer asks the vector index factory to create an indexer for a predicate. If factorySpec.CreateIndex returns an error (e.g. invalid vector dimension or unsupported index parameters in the schema), the error is wrapped with the predicate name and propagated up through addVectorEntry, aborting the bulk load for that predicate.

Source

Thrown at dgraph/cmd/bulk/vector_indexer.go:221

	if indexer, ok := vi.indexers[pred]; ok {
		return indexer, vi.txnCaches[pred], nil
	}

	// Check if this predicate has a vector index spec
	spec, ok := vi.indexSpecs[pred]
	if !ok {
		return nil, nil, fmt.Errorf("no vector index spec for predicate %s", pred)
	}

	// Create the HNSW indexer
	factorySpec, err := tok.GetFactoryCreateSpecFromSpec(spec)
	if err != nil {
		return nil, nil, fmt.Errorf("error getting factory spec for %s: %w", pred, err)
	}

	indexer, err := factorySpec.CreateIndex(pred)
	if err != nil {
		return nil, nil, fmt.Errorf("error creating indexer for %s: %w", pred, err)
	}

	// Create transaction cache
	txn := posting.NewTxn(vi.state.writeTs)
	viTxn := posting.NewViTxn(txn)
	tc := hnsw.NewTxnCache(viTxn, vi.state.writeTs)

	vi.indexers[pred] = indexer
	vi.txnCaches[pred] = tc
	vi.txns[pred] = txn
	vi.vectorPreds[pred] = true

	glog.Infof("Lazily initialized HNSW indexer for predicate %s (shard %d)", pred, vi.shardId)

	return indexer, tc, nil
}

// isVectorPredicate returns true if the given predicate has a vector index.

View on GitHub (pinned to 759e242be6)

Solutions

  1. Read the wrapped inner error and fix the underlying cause reported by CreateIndex for the named predicate.
  2. Align vector data dimensions with the predicate's schema (e.g. float32vector @index(vector) size).
  3. Drop and re-apply the vector index in the schema so the factory spec is regenerated, then rerun the bulk loader.
  4. Validate the schema (dgraph schema) before bulk loading to catch dimension/spec problems early.

Example fix

// before
// schema: embedding: float32vector @index(vector) .   (data has 768-dim, schema default 4-dim mismatch)
// after
// schema: embedding: float32vector @index(vector(768)) .
// then rerun: dgraph bulk -f data.rdf -s schema
Defensive patterns

Strategy: try-catch

Validate before calling

// before bulk load: verify vector dims match schema
schema, err := c.Schema(context.Background(), nil)
if err != nil { return err }
for _, p := range schema.Types {
	if strings.Contains(p, "float32vector") && dataDim(p) != schemaDim(p) {
		return fmt.Errorf("vector dimension mismatch on %s", p)
	}
}

Try / catch

indexer, txn, err := vi.getOrCreateIndexer(pred)
if err != nil {
	var wrappedErr error
	if errors.As(err, &wrappedErr) && strings.Contains(err.Error(), "error creating indexer") {
		log.Error("vector index creation failed", "pred", pred, "cause", errors.Unwrap(err))
		return fmt.Errorf("fix schema/data for %s: %w", pred, errors.Unwrap(err))
	}
	return err
}

Prevention

When it happens

Trigger: Running dgraph bulk loader on a schema where a predicate has vector-type data but CreateIndex fails — typically mismatched vector dimensions vs. the schema-declared dimension, or an unsupported/invalid vector index configuration on the predicate.

Common situations: Schema changed after data was written (dimension mismatch); bulk loading data whose embedding size differs from the @vector(dim) in the schema; corrupted or incompatible vector index spec in the schema.

Related errors


AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/4c50189d7818cdd8. Report an issue: GitHub.