What causes "error while getting object count for shard %s: %w" in weaviate/weaviate?

Check the wrapped error and verify the shard directory and sidecar files exist and are readable by the weaviate process.

weaviate/weaviate · error

error while getting object count for shard %s: %w

Error message

error while getting object count for shard %s: %w

What it means

ObjectCountAsync computes the object count of an unloaded shard by scanning segment sidecars on disk via shardusage.CalculateUnloadedObjectsMetrics. This error wraps a failure of that directory listing/parse (unreadable shard directory, missing or corrupt sidecar files). Nothing is cached on failure, so every subsequent call retries the listing and fails again.

Source

Thrown at adapters/repos/db/shard_lazyloader.go:287

	l.mutex.Lock()
	defer l.mutex.Unlock()

	if l.loaded {
		return l.shard.ObjectCountAsync(ctx)
	}
	if l.unloadedCount != nil {
		return *l.unloadedCount, nil
	}

	// The disk read stays under the lock: a load writes segment sidecars and
	// recovers the write-ahead log, so a read overlapping one can sum a mix of
	// old and new segments and then cache the result. Everything else on this
	// shard waits for one directory listing. A failed read caches nothing, so a
	// shard whose sidecars stay unreadable repeats that listing on every call.
	idx := l.shardOpts.index
	objectUsage, err := shardusage.CalculateUnloadedObjectsMetrics(idx.logger, idx.path(), l.shardOpts.name, true)
	if err != nil {
		return 0, fmt.Errorf("error while getting object count for shard %s: %w", l.shardOpts.name, err)
	}

	count := objectUsage.Count
	l.unloadedCount = &count

	return count, nil
}

func (l *LazyLoadShard) GetPropertyLengthTracker() *inverted.JsonShardMetaData {
	l.mustLoad()
	return l.shard.GetPropertyLengthTracker()
}

func (l *LazyLoadShard) PutObject(ctx context.Context, object *storobj.Object) error {
	if err := l.Load(ctx); err != nil {
		return err
	}
	return l.shard.PutObject(ctx, object)

View on GitHub (pinned to 75aa4b6d11)

Solutions

Check the wrapped error and verify the shard directory and sidecar files exist and are readable by the weaviate process.
Fix filesystem permissions or restore/repair the shard directory (e.g. from replication or backup).
Recreate/re-sync the shard from a replica if files are corrupt.
After repair, call ObjectCountAsync again so the count is cached.

Defensive patterns

Strategy: retry

Validate before calling

// verify the shard directory is readable before asking for counts
if _, err := os.ReadDir(filepath.Join(dataPath, className, shardName)); err != nil {
	return fmt.Errorf("shard dir unreadable: %w", err)
}

Try / catch

count, err := shard.ObjectCountAsync(ctx)
if err != nil {
	logger.Warnf("object count unavailable for shard %s: %v", shardName, err)
	return lastKnownCount, nil // fallback: nothing was cached, so serve last known value
}

Prevention

Ensure the weaviate process owns and can read all shard directories.
Restore broken shards from replicas or backups promptly.
Watch for repeated 'error while getting object count' logs — nothing is cached on failure, so each call re-lists the directory.
Avoid moving/deleting shard files while the node runs.

When it happens

Trigger: Calling ObjectCountAsync on a cold shard whose shard directory or segment sidecar files are unreadable, deleted, or corrupted.

Common situations: Shard files partially deleted or moved on disk; permission problems on the data directory; corruption from a crash; monitoring/replication tooling polling counts on a shard with broken sidecars.

Related errors

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