What causes "get vector of docID %d" in weaviate/weaviate?

Read the wrapped root cause in the logs and fix the storage layer (disk full, permissions, I/O errors).

get vector of docID %d

Error message

get vector of docID %d

What it means

While fetching a candidate's vector to compute its distance during rescoring, any error that is NOT a recoverable storobj.ErrNotFound is wrapped with 'get vector of docID %d'. Typed ErrNotFound (deleted nodes) are handled by tombstoning the node; this wrapper indicates a different storage-level failure retrieving the vector for that node. The nodeID in the message is the internal HNSW node/document id.

Source

Thrown at adapters/repos/db/vector/hnsw/search.go:690

		vec, err = h.TempVectorForIDWithViewThunk(ctx, nodeID, slice, view)
	} else {
		docID, relativeID := h.cache.GetKeys(nodeID)
		vecs, err := h.TempMultiVectorForIDWithViewThunk(ctx, docID, slice, view)
		if err != nil {
			return 0, err
		} else if len(vecs) <= int(relativeID) {
			return 0, errors.Errorf("relativeID %d is out of bounds for docID %d", relativeID, docID)
		}
		vec = vecs[relativeID]
	}
	if err != nil {
		var e storobj.ErrNotFound
		if errors.As(err, &e) {
			h.handleDeletedNode(nodeID, "distanceFromBytesToFloatNodeWithView")
			return 0, err
		}
		// not a typed error, we can recover from, return with err
		return 0, errors.Wrapf(err, "get vector of docID %d", nodeID)
	}
	// Normalize in-place since vec points to a pooled slice that will be
	// returned after this function. This avoids allocating a new slice
	// for every vector during rescoring.
	h.normalizeVecInPlace(vec)
	return concreteDistancer.DistanceToFloat(vec)
}

func (h *hnsw) distanceToFloatNode(distancer distancer.Distancer, nodeID uint64) (float32, error) {
	candidateVec, err := h.vectorForID(context.Background(), nodeID)
	if err != nil {
		return 0, err
	}

	dist, err := distancer.Distance(candidateVec)
	if err != nil {
		return 0, errors.Wrap(err, "calculate distance between candidate and query")
	}

View on GitHub (pinned to 75aa4b6d11)

Solutions

Read the wrapped root cause in the logs and fix the storage layer (disk full, permissions, I/O errors).
Restore from backup and re-index the shard whose store is corrupted.
Run a consistency check / compaction of the affected shard's LSM store.
If a specific object is corrupt, delete and re-push that object to regenerate its vector.

Defensive patterns

Strategy: try-catch

Try / catch

res, err := client.GraphQL().Get().Do(ctx)
if err != nil && strings.Contains(err.Error(), "get vector of docID") {
    // treat as storage corruption: alert, check disk/store, consider backup restore
}

Prevention

Use clean shutdowns; avoid killing the process during writes
Monitor filesystem health (space, IO errors) on data volumes
Schedule periodic backups and verify restore procedures

When it happens

Trigger: distanceFromBytesToFloatNodeWithView: TempVectorForIDWithViewThunk (or the multivector thunk) returns a non-ErrNotFound error for nodeID while a compressed index is being rescored — e.g. disk I/O error, checksum failure, or corrupt vector bytes in the LSM store.

Common situations: Disk failures or a crashed write leaving a torn vector record; running with a corrupted persistent store after an unclean shutdown; store files deleted or permission problems at the filesystem level.

Related errors

AI-assisted analysis of weaviate/weaviate@75aa4b6d11 (2026-09-04). Data as JSON: /api/errors/86dfe83bfa502ec1. Report an issue: GitHub.