weaviate/weaviate · error

can not assign new nodes to shard %s, it didn't exist in the

Error message

can not assign new nodes to shard %s, it didn't exist in the new partitions

What it means

During unfreeze, GetPartitions succeeded but the resulting partitions map has no entry for the tenant's shard, so no new node assignment can be made. The tenant entry is nulled and this error is returned, leaving the tenant unfrozen-but-unassigned (operation aborted).

Source

Thrown at cluster/schema/meta_class.go:733

// unfreeze creates a process requests and add them in memory to compare it later when
// TenantProcessRequest comes.
// it keeps the requested state ACTIVE/INACTIVE in memory.
// it updates the tenant status to UNFREEZING in RAFT schema.
// NOTE: can make some of the requests nil.
func (m *metaClass) unfreeze(nodeID string, i int, req *command.UpdateTenantsRequest, p *sharding.Physical) error {
	name := req.Tenants[i].Name
	process := m.shardProcess(name, command.TenantProcessRequest_ACTION_UNFREEZING)

	partitions, err := m.Sharding.GetPartitions(req.ClusterNodes, []string{name}, m.Class.ReplicationConfig.Factor)
	if err != nil {
		req.Tenants[i] = nil
		return fmt.Errorf("get partitions: %w", err)
	}

	newNodes, ok := partitions[name]
	if !ok {
		req.Tenants[i] = nil
		return fmt.Errorf("can not assign new nodes to shard %s, it didn't exist in the new partitions", name)
	}

	oldNodes := p.BelongsToNodes
	p.Status = types.TenantActivityStatusUNFREEZING
	p.BelongsToNodes = newNodes

	newToOld := map[string]string{}
	slices.Sort(newNodes)
	slices.Sort(oldNodes)

	for idx, node := range newNodes {
		if idx >= len(oldNodes) {
			// ignore new nodes if the replication factor increase
			// and relay on replication client will replicate the data
			// after it's downloaded
			continue
		}
		newToOld[node] = oldNodes[idx]

View on GitHub (pinned to 75aa4b6d11)

Solutions

  1. Verify the tenant still exists in the class's sharding state and that the class wasn't recreated; re-check with GetTenants
  2. Recompute/re-sync the sharding state across the cluster (schema manager rebuild or restore from a consistent snapshot)
  3. Delete and re-add the tenant if its shard is genuinely gone, accepting data implications for the offloaded (COLD) tenant
  4. Check node membership and replication factor consistency — GetPartitions output depends on req.ClusterNodes and the class replication config

Example fix

// before
clients.UpdateTenants(class, []Tenant{{Name: t, Status: HOT}}) // shard missing after class rebuild
// after
tenants, _ := clients.GetTenants(class)
if _, ok := tenants[t]; !ok { clients.AddTenants(class, []Tenant{{Name: t, Status: HOT}}) } else { clients.UpdateTenants(...) }
Defensive patterns

Strategy: validation

Validate before calling

tenants, err := getTenants(class)
if _, ok := tenants[tenant]; !ok { return ErrTenantShardMissing }

Type guard

func shardExists(partitions map[string][]string, tenant string) bool {
  _, ok := partitions[tenant]
  return ok
}

Prevention

When it happens

Trigger: UpdateTenants unfreeze path where partitions[name] lookup misses — the shard disappeared from the recomputed sharding state, e.g. after sharding state corruption, tenant deletion racing unfreeze, or class recreation.

Common situations: Unfreezing a tenant whose shard was removed while frozen (tenant deleted, class rebuilt); mismatches between the sharding state snapshot used at freeze time and the current one; multi-node cluster where one node has stale schema state.

Related errors


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